5 ms·

Any team with enough developers using Node should develop a handful who can understand the v8 internals and help troubleshoot real-world performance problems.

by nwhatt 9y ago

Any team with enough developers using Node should develop a handful who can understand the v8 internals and help troubleshoot real-world performance problems. The most helpful resource I've found about v8 specific performance is the bluebird optimization killers wiki: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k... wiki, and the v8 bailout reasons repo: https://github.com/vhf/v8-bailout-reasons https://github.com/vhf/v8-bailout-reasons

gbuk2013 9y ago
Except Crankshaft is replaced with Turbofan in Node.js 8+ so a lot of these no longer apply.
- vhf 9y ago
  (I'm the author of this last repo.) You are correct that these no longer apply to the most recent Node versions. Crankshaft is still being used in Node <8.3.0. Crankshaft got totally disabled starting from V8 5.9. Node 8.2.1 uses V8 5.8.283.41, Node 8.3.0 uses V8 6.0.286.52. I'm pretty sure there is still a big number of projects running on Node <= 8.3.0. I'll make it clear in this project README though, whenever I find time. :)
  - gbuk2013 9y ago
    True, except if you track LTS (probably not a bad strategy) and entirely skip the earlier 8.x versions ;)
jcranmer 9y ago
The best advice I can give about performance engineering is "all performance guidelines are bullshit." Compilers and JITs are constantly improving, which means any specific guideline like "do X to avoid a JIT bailout" isn't necessarily true going forward. Furthermore, the benchmarks that compiler writers use to assess the utility of their optimizations aren't hand-optimized unreadable kludges, it's generally typical applications. Write readable, natural code, and compilers are more likely to eventually optimize it, even if perhaps they do a bad job today. Only contort your code to improve performance if you have profiles showing that you need to do so, and even then, see if there's natural code that works first.
- tejinderss 9y ago
  Do you think adding type annotations or using typed js (typescript/flow), the optimisations could be improved? Since the types are providing more metadata about the code?
  - jcranmer 9y ago
    No (with an asterisk). The state-of-the-art for JS optimization already computes shape information (roughly equivalent to typing) and feeds that into optimizations. The asterisk comes from the costs of having multiple shapes for a given variable. V8 (to my recollection, it could very well be out of date) generally has a performance cliff between monomorphic and polymorphic functions: if the added strictures of typechecking is giving you monomorphic functions, it could see a performance improvement. Other JITs (again, to my recollection) are generally happier to have polymorphic functions where the degree of divergence is still small (say, two or three shapes), although having 1000 shapes is going to be unhappy for everybody. Note that this discussion is effectively microoptimization-level discussion: don't rearchitect your code to enforce monomorphism at the expense of clarity unless you have profiling evidence that the performance is necessary.

by nwhatt 9y ago

gbuk2013 9y ago

Except Crankshaft is replaced with Turbofan in Node.js 8+ so a lot of these no longer apply.

vhf 9y ago
(I'm the author of this last repo.) You are correct that these no longer apply to the most recent Node versions. Crankshaft is still being used in Node <8.3.0. Crankshaft got totally disabled starting from V8 5.9. Node 8.2.1 uses V8 5.8.283.41, Node 8.3.0 uses V8 6.0.286.52. I'm pretty sure there is still a big number of projects running on Node <= 8.3.0. I'll make it clear in this project README though, whenever I find time. :)
- gbuk2013 9y ago
  True, except if you track LTS (probably not a bad strategy) and entirely skip the earlier 8.x versions ;)

jcranmer 9y ago

The best advice I can give about performance engineering is "all performance guidelines are bullshit." Compilers and JITs are constantly improving, which means any specific guideline like "do X to avoid a JIT bailout" isn't necessarily true going forward. Furthermore, the benchmarks that compiler writers use to assess the utility of their optimizations aren't hand-optimized unreadable kludges, it's generally typical applications. Write readable, natural code, and compilers are more likely to eventually optimize it, even if perhaps they do a bad job today. Only contort your code to improve performance if you have profiles showing that you need to do so, and even then, see if there's natural code that works first.

tejinderss 9y ago
Do you think adding type annotations or using typed js (typescript/flow), the optimisations could be improved? Since the types are providing more metadata about the code?
- jcranmer 9y ago
  No (with an asterisk). The state-of-the-art for JS optimization already computes shape information (roughly equivalent to typing) and feeds that into optimizations. The asterisk comes from the costs of having multiple shapes for a given variable. V8 (to my recollection, it could very well be out of date) generally has a performance cliff between monomorphic and polymorphic functions: if the added strictures of typechecking is giving you monomorphic functions, it could see a performance improvement. Other JITs (again, to my recollection) are generally happier to have polymorphic functions where the degree of divergence is still small (say, two or three shapes), although having 1000 shapes is going to be unhappy for everybody. Note that this discussion is effectively microoptimization-level discussion: don't rearchitect your code to enforce monomorphism at the expense of clarity unless you have profiling evidence that the performance is necessary.