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 -- Mailing list: https://launchpad.net/~unity-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~unity-dev More help : https://help.launchpad.net/ListHelp
