-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve mixin performance by fixing https://code.google.com/p/v8/issues/detail?id=4165 #1982
Conversation
Wow, that's dramatic indeed. I'm starting to think we need a more complete jade performance testing suite to be setup. One thought: instead of generating the many redundant I am slightly concerned by how much we are optimising for specific V8 bugs here. I think changes like this should be explicitly marked out with comments in the code that explain:
|
Well the bad news is that they don't intend on fixing it as they have made a conscious decision to not optimize this case in favour of something else, but I keep fighting the fight ;) https://code.google.com/p/v8/issues/detail?id=4165#c4 |
jade_interp is much more suited for the dirty job. It also makes the PR backwards-compatible. |
Excellent work :). Let's give the v8 team another day or two in case they re-consider. assuming they don't change their minds, we can implement this hack while we look for a more per enact solution. In particular, I'd like to try making mixing be functions that return strings (rather than append to the buffer). We could then identify "pure" mixing (I.e. Those that don't depend on any locals) and hoist them outside of the template. |
👍 |
+1. It looks clean enough and the performance improvements are nontrivial. |
OK, lets get this released :) |
improve mixin performance by fixing https://code.google.com/p/v8/issues/detail?id=4165
(Part of #1975)
Found another weird bug in v8 - see jsperf http://jsperf.com/iterative-function-creation and v8 issue https://code.google.com/p/v8/issues/detail?id=4165
Anyhow, fixing it turns this
into
This PR assumes that all variables with names like
jade_mixin_N
are safe to use. If we don't want to make this assumption for the 1.x releases, we should bring it in 2.0. What do you think?