On 05/24/2012 06:20 PM, Marco Trevisan (Treviño) wrote: > 2012/5/24 Mikkel Kamstrup Erlandsen <[email protected]>: > >> 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. > Yes, that's the same thing I meant... Having an our class that handles > most of timeouts into the unity code could just help in future to > switch to that, just acting on that class instead of refactoring the > current code. >
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. Of course there are some drawbacks - timeouts can only be added from the same thread and it currently uses void* to identify the timeouts (instead of uint), moreover removing the same timeout multiple times could be more dangerous. But despite these, I think your branch could make good use of it (or some variation of it). -- Mailing list: https://launchpad.net/~unity-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~unity-dev More help : https://help.launchpad.net/ListHelp
