unity-dev team mailing list archive

[Michal Hruby <michal.hruby@xxxxxxxxxxxxx>]

On 05/26/2012 01:29 AM, Michal Hruby wrote:
> On Sat 26 May 2012 01:25:05 AM CEST, Michal Hruby wrote:
>> I implemented a custom GSource that allows adding of multiple timeouts
>> to this single source, I profiled this somewhat (against standard
>> timeout sources) and when using 8 different timeouts, the single custom
>> source requires 2.5x fewer lock calls (g_mutex_lock), ~6% fewer
>> instructions are executed and ~10% fewer branches.
>>
> Sorry, it's late :P here's a link to the custom source - 
> http://ubuntuone.com/2f9boSuvqS8zhgUcJqMry2
>

As Sam pointed out on IRC, compiz is using something very similar, so I
took that for a spin and tried to compare the two - what I noticed was
that compiz's CompTimers have very low time deviation when using
repeating timers (one needs to recompute the expiration time when the
dispatch finishes and that always adds a few microseconds to the
intended interval) - it was about 10x less than my implementation. So I
dug into that and noticed that CompTimers are slightly "cheating" - the
timers can fire up to 500us sooner than intended, but it's pretty nice
trick, so I'm using it now as well :)

As for the actual numbers, it's very similar - CompTimers use around 15%
fewer locks (as they aren't using GSource.get_time which can lock the
MainContext), but also ~5 times as many clock_gettime(). Bottomline, the
implementations are almost equivalent, and if compiz wants to get rid of
glibmm dependancy, it could use this.

A "fun" tidbit - when I was using callgrind to profile the two, the
initialization that boost/glibmm/whatever need to do before calling
main() of my test app accounts for 40% of all executed instructions.

Michal