[Webkit-unassigned] [Bug 137485] [GLIB] Split GMainLoopSource moving thread safe implementation to its own class GThreadSafeMainLoopSource

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=137485





--- Comment #7 from Zan Dobersek <zandobersek at gmail.com>  2014-10-09 03:07:53 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > Still, in my experience the main bottleneck in GMainLoopSource is the constant creation and destruction of GSource objects. I'd prefer to see that addressed first, and work on thread-safety simplification from there.
> 
> Constant creation and destruction of GSources is the normal way glib main loop works, so I'm surprised that causes problems. g_idle and g_timeout functions in glib always create a new GSource, so there shouldn't be differences in that regard between using glib functions directly or GMainLoopSource. 
> I haven't measured but I would say that creating a GCancellable (which is a GObject), and the mutex lock/unlock on every schedule is a lot more demanding than creating and destroying the sources.
> 

I profiled the current situation, your patch and my work in progress. The test case is a simple loop via setTimeout(loop, 1), which is handled by the shared timer is throttled to 250 iterations per second.

Current state: http://people.igalia.com/zdobersek/gms-current.png
Horrible, spends 24% of overall time under GMainLoopSource::scheduleAfterDelay(). That's a quarter of runtime to create and attach ~250 GSource objects per second.

Your patch: http://people.igalia.com/zdobersek/gms-optional-thread-safety.png
Already does wonders, dropping the time under GMainLoopSource::scheduleAfterDelay() to a bit under 14% of overall time.

The simple source WIP: http://people.igalia.com/zdobersek/gms-simplified.png
Uses a single GSource object, and it shows. Scheduling the callback dispatch (which at this point is just setting the ready time on the source) only takes 4% of the runtime, and there's basically no GObject churn.

Comparing the time spent under the GSource dispatch function, it goes from ~52% down to ~27% and further down to ~14%.


There's no problem in constant creation and destruction of GSource objects in terms of correctness, but it's disturbing in the terms of performance. Feel free to proceed with this patch, it actually already improves things more than I would've expected. But I want to address these high-intensity timers that can hinder performance, starting probably with the shared timer and the flush timer in LayerTreeHostGtk. The simple implementation I outlined in bug #137513 does that, but needs discussion and some sort of approval.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.