-
Notifications
You must be signed in to change notification settings - Fork 28.8k
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
querystring: optimize parse and stringify #847
Conversation
Do you have a link to something that explains this one? |
@vkurchatkin No particular link. I saw someone mention it in one of the other PRs and thought I'd try it out. It's not a huge performance boost, but there was a difference. |
My general rule is make a var where there are are 3-4+ references to like a |
Ok, after looking through v8 I found some hints that |
Double negation considered slower than a straight null check.
PR-URL: #847 Reviewed-By: Brendan Ashworth <brendan.ashworth@me.com>
Don't merge just yet, I think I may have some further improvements at least for parse... |
Ok, scratch that. For some reason I see a larger increase with my uncommitted changes to parse() than the current committed changes with benchmark.js-based benchmarks but not so with the io.js querystring benchmarks (same inputs). I'm ok with this current implementation for now though. Thoughts? |
3a34127
to
88e00f8
Compare
if (str.length === 0) | ||
return str; | ||
|
||
var len = str.length; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be worth it to bump this line up before the str.length === 0
check?
parse optimizations: * Move try-catch to separate function to keep entire function from being deoptimized. * Use key array lookup instead of using hasOwnProperty. * Avoid decoding known empty strings. * Avoid possibly unnecessary switch to slower decoder for values if key decoding throws. stringify optimizations: * Use manual loop for default encoder instead of encodeURIComponent. * Use string concatenation instead of joining an array of strings. * Avoid caching result of typeof.
88e00f8
to
6610767
Compare
I'm cool with this. |
Everything look alright for merging this? /cc @iojs/collaborators |
We should see what the CI says before merging. https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/245/ |
parse optimizations: * Move try-catch to separate function to keep entire function from being deoptimized. * Use key array lookup instead of using hasOwnProperty. * Avoid decoding known empty strings. * Avoid possibly unnecessary switch to slower decoder for values if key decoding throws. stringify optimizations: * Use manual loop for default encoder instead of encodeURIComponent. * Use string concatenation instead of joining an array of strings. * Avoid caching result of typeof. PR-URL: nodejs#847 Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Landed in 85a92a3. |
Notable Changes: * path: New type-checking on path.resolve() <#1153> uncovered some edge-cases being relied upon in the wild, most notably path.dirname(undefined). Type-checking has been loosened for path.dirname(), path.basename(), and path.extname(), (Colin Ihrig) <#1216>. * querystring: Internal optimizations in querystring.parse() and querystring.stringify() <#847> prevented Number literals from being properly converted via querystring.escape() <#1208>, exposing a blind-spot in the test suite. The bug and the tests have now been fixed (Jeremiah Senkpiel) <#1213>.
@vkurchatkin I'd be grateful if you could point me on such hints. It sound really interesting to me, but I couldn't find any confirmations. |
parse optimizations:
being deoptimized.
key decoding throws.
stringify optimizations:
Results with benchmarks from #846: