-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
benchmark: add microbenchmarks for ES Map #7581
Conversation
const assert = require('assert'); | ||
|
||
const bench = common.createBenchmark(main, { | ||
method: ['pojo', 'fakeMap', 'map'], |
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.
pojo
?
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.
plain old javascript object ... comes from plain old java object, maybe that's just for us old java dogs
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.
I'll just call it 'object' since it's not obvious
Not sure if it matters, but it might be nice to have one for |
ok, s/pojo/object and added one for a null-prototype object
|
Should this utilize |
|
||
function runObject(n) { | ||
const m = {}; | ||
let i = 0; |
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.
I think we're still preferring var
over let
.
s/let/var, thanks for pointing that out. I don't know if this is a candidate for |
I'll defer to someone with more experience working on the benchmarks, but |
AFAIK that should be (million) ops/sec, so technically |
Interesting! Unmodified version:
Modified to include map creation on each loop:
|
ok then, that is interesting and explains why fakeMap looked "better" than the pojo, perhaps we go ahead and migrate |
@rvagg That would probably have to happen at least in v7 or later since that would be a pretty big change. |
The number should be the higher the better? |
@simonkcleung Yes. Values are always operations per second. |
Moving the querystring and headers objects to Maps definitely makes sense given the perf results but @Fishrock123 is right about targeting such a change for v7. We can likely go ahead and get that change landed in master now as a semver-major. |
var i = 0; | ||
bench.start(); | ||
for (; i < n; i++) { | ||
m['i' + n] = n; |
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.
Are we trying to set the same two properties ('i10000000'
and 's10000000'
) 10 million times? If so, maybe use keys like 'a', 'b'
. Or should the keys be 'i' + i
and 's' + i
?
@rvagg Thanks for putting this together. When we're using named keys Every time we add a property to an object, we create a new transition map. Only if we add properties in exactly the same order can we reuse the maps. This is often not the case, for example when we parse request headers into So +1 for moving to maps! |
btw, LGTM for getting this landed. :-) |
@rvagg ... is this ready to land? |
I think @fhinkel’s comment should still be addressed? |
ping @rvagg |
Thanks for catching that @fhinkel, that changes everything! Updates pushed, pls review folks. v6
master
|
LGTM. Should we update the first comment with the new times and also point out, that it's ops/sec rather than seconds (so higher is faster). |
Good idea, done! @fhinkel is there a known speed regression for maps in later V8? We're comparing 5.1 to 5.4 here and that's a big slowdown, or could the test not be getting at the real numbers? |
I wonder if something else was going on during the benchmarking, because |
yea, I think you're right, new run on master:
|
Too much variability between runs, bumping it back up to the millions and it stabilises a bit more: v6
master
|
I think we can blame the variation on timing issues. I don't get a regression going from Node v6.0.0:
Node v6.7.0:
Node master:
|
c133999
to
83c7a88
Compare
landed @ 07cc9df |
PR-URL: #7581 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <ranziska.hinkelmann@gmail.com>
PR-URL: #7581 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <ranziska.hinkelmann@gmail.com>
PR-URL: #7581 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <ranziska.hinkelmann@gmail.com>
PR-URL: #7581 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Franziska Hinkelmann <ranziska.hinkelmann@gmail.com>
Given the discussion in #6102 about
Map
still being too slow to use I figured I'd see with a benchmark. @mscdex, @jasnell please review and let me know if you think this is valid.As for why the fakeMap test is faster ... I got nothing ...
Update after @fhinkel noticed a serious flaw:
v6
master
Times are ops/sec, so higher is better