buffer: improve Buffer.from performance #15178
Conversation
Using == null in code paths that are expected to mostly receive objects, arrays or other more complex data types is not ideal because typecasting these types is very slow. Change to instead check === null || === undefined. Also move one variable assignment in fromString after an if condition that doesn't need it (and returns if truthy). Refs: https://jsperf.com/triple-equals-vs-double-equals/3
nodejs-github-bot
added
the
buffer
apapirovski
force-pushed
the
patch-buffer-from-perf
branch
from
99f480d
to
f9fbc3a
Compare
|
There are other parts of code outside of Buffer that extensively use |
|
/cc @bmeurer what do you think? I'd expect this to be optimizable by the engine but maybe I'm missing something about the spec? |
|
Node doesn't have cc @psmarshall |
mscdex
added
the
performance
|
(Probably off-topic but) what about |
|
@Kovensky see https://html.spec.whatwg.org/multipage/obsolete.html#dom-document-all for more info |
|
I see (a quick search just said that was non-standard and “do not use”). Thanks for the reference. Maybe one day it could be optimized in browsers too by only being pessimistic if |
|
@Kovensky, FWIW also see tc39/ecma262#673, which brings the odd behaviors of |
|
It would be great if v8 handles this better but it will take a while until this would get into Node.js. This is a trivial fix that improves the current situation and therefore I would definitely like to land this. |
|
It would be nice to have V8 optimize the single equals case for |
|
@mscdex but you do not mind landing this for the time being, do you? Because if you are good with this, it could land. |
|
@BridgeAR It's fine for now I suppose. |
|
Landed in fc1fa4e |
Using == null in code paths that are expected to mostly receive objects, arrays or other more complex data types is not ideal because typecasting these types is very slow. Change to instead check === null || === undefined. Also move one variable assignment in fromString after an if condition that doesn't need it (and returns if truthy). PR-URL: #15178 Refs: https://jsperf.com/triple-equals-vs-double-equals/3 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Using == null in code paths that are expected to mostly receive objects, arrays or other more complex data types is not ideal because typecasting these types is very slow. Change to instead check === null || === undefined. Also move one variable assignment in fromString after an if condition that doesn't need it (and returns if truthy). PR-URL: nodejs#15178 Refs: https://jsperf.com/triple-equals-vs-double-equals/3 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Using == null in code paths that are expected to mostly receive objects, arrays or other more complex data types is not ideal because typecasting these types is very slow. Change to instead check === null || === undefined. Also move one variable assignment in fromString after an if condition that doesn't need it (and returns if truthy). PR-URL: #15178 Refs: https://jsperf.com/triple-equals-vs-double-equals/3 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com>
MylesBorins
added
the
baking-for-lts
|
should this land in LTS? If so it will need to bake a bit longer. Please change labels as appropriate |
|
Not certain. I'll need to run benchmarks to see if this change makes a difference on v6.x given the different V8. That said, if it does make a difference this might be possible to backport almost immediately since it doesn't functionally change anything just makes the check more V8 friendly. |
MylesBorins
removed
the
baking-for-lts
Using
== nullin code paths that are expected to mostly receive objects, arrays or other more complex data types is not great because typecasting these types is very slow. Change to instead check=== null || === undefined.Here's the benchmark:
and here's the old vs old, just to show that the string slowdown is probably just within margin of error:
For reference, == vs === is about 10x slower: https://jsperf.com/triple-equals-vs-double-equals/3
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
buffer