I just ran into the following posting by Chris Dickinson which is extremely insightful and also very clear
(or as clear as it can be given the abstruse subject matter)
http://neversaw.us/2013/09/04/on-the-performance-of-closures-in-v8/
The bottom line is "Code in closures CAN be inlined - but only so long as it doesn't close over anything".
This is in general bad news for our "that-ist" architecture but I believe it will in the end be possible to
adopt "internal this-ism" as a performance optimisation, hidden from the user. Interestingly since we no
longer visibly adopt that-ism (that is, the user no longer writes a closure for their components) we are
already halfway out of the problem - our global free functions which we now like to code with can all be
inlined very merrily. Unfortunately the framework's current generated wrappers for them (as seen in invokers
and listeners) can't. Of course this is by far the least of the framework's performance problems right now -
but for those of us trying to write very high-performance code in little areas outside the framework's view
(Colin!) this post is very well worth reading :)
Cheers,
A
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
