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? |
mscdex
force-pushed
the
perf-querystring
branch
from
3a34127
to
88e00f8
Compare
| if (str.length === 0) | ||
| return str; | ||
|
|
||
| var len = str.length; |
There was a problem hiding this comment.
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.
mscdex
force-pushed
the
perf-querystring
branch
from
88e00f8
to
6610767
Compare
|
I'm cool with this. |
Fishrock123
added
the
querystring
|
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: