unity-dev team mailing list archive

[Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxxxxxx>]

On 05/23/2012 09:38 PM, Marco Trevisan (Treviño) wrote:
> 2012/5/23 Mikkel Kamstrup Erlandsen<mikkel.kamstrup@xxxxxxxxxxxxx>:
> > One thing we might wanna look at is how many GSources we create. I read
> > somewhere that someone saved a lot of time changing to having his callbacks
> > share a single GSource, instead of creating and attaching a gajillion
> > sources. This is not just for UBus of course, but in anything perf critical
> > (nux/unity/compiz jumps to mind).
>
> A precise answer? A lot! :)
> I'm currently porting unity to use a GSource wrapper (glib::Source) I
> wrote to be more C++ friendly, (even if it could lead to some
> overhead, but it's pretty simple and it gives development
> benefits...). However, if you just try this branch
> lp:~3v1n0/unity/move-to-gsource-wrapper adding some debug bits into
> UnityCore/GLibSource* you'll notice how many sources we use,
> especially on Dash Initialization.
>
> Currently glib::Source is very simple and I've only designed it to
> wrap the glib struct, but probably we could improve that also to be
> reused.

If we actually use that many you might try to reduce memory 
fragmentation by making the glib::Source class castable to a GSource 
(ie. by having a GSource value as the first member in the struct). Or if 
glib::Source is primarily stack allocated this doesn't matter, of course.

Considering "reuse" of sources I am not sure I like the word "reuse" 
since that seems something that could be error prone. I'd rather see it 
done by using some (thread safe) global static sources that we attach 
closures to so to say.

For example - I don't see any particular reason that one would ever need 
more than one timeout source in an entire app lifetime. There could be 
one global timeout source that managed a (sorted) list of timeout 
closures.  Same goes for idle sources in fact.

Cheers,
Mikkel