-
Notifications
You must be signed in to change notification settings - Fork 30k
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 benchmarks for Buffer.from()
#8738
Conversation
Adds benchmarks for `Buffer.from()` and its various argument combinations. Ref: nodejs#8733
Ouch! Even if these "micro benchmarks" are not 100% accurate, they could still be good for discovering large deltas. |
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.
LGTM
Yeah. The difference actually seems pretty reproducible to me, so I’m going to starting bisecting now… |
Those are, unfortunately, the V8 5.4 update from #8317. /cc @nodejs/v8 (For completeness: benchmark results at all bisect points; bisected from the v6.0.0 release up to the current HEAD.) |
@addaleax ... ouch. That's a big drop. For the bench mark itself, can you perhaps move each case into a separate function then use |
@jasnell I can try that later, but since you’re obviously having something in specific in mind and I’ll be afk for a bit, feel free to use the |
heh... yeah, considered that but I need to be away from the keyboard for a bit also (my two boys have a cross country track meet at school and they need a cheering section). When I get back on later today I'll see what I can work up. |
I found the cause of the regression: In the |
@jasnell it doesn’t seem to have much of an effect. Would you still prefer that change? |
No that's OK. Given what appears to be the cause of the regression, it's On Friday, September 23, 2016, Anna Henningsen notifications@github.com
|
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.
LGTM
Landed in 289d862 |
We improved spread-super performance (my microbenchmark is as fast in 5.8 as it was in 5.1 when it wasn't spec compliant). Can we revisit this, once we have 5.8 in Node? |
What exactly? The change in #8754? I would assume we could just revert that if we want and it doesn’t have an performance impact. |
All I meant was to re-run the benchmarks. But we'll do that anyways. Sorry for the confusion. I got to excited by the performance improvements. |
Checklist
make -j8 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected core subsystem(s)
benchmarks
Description of change
Adds benchmarks for
Buffer.from()
and its various argument combinations.Ref: #8733
It also looks like there’s a performance regression on the current
master
that isn’t on v6 and which exceeds the one described in #8733 notably::(