Optimize your Node app by upgrading Node.js
blog.sqreen.io
blog.sqreen.io
http://benediktmeurer.de/2017/03/01/v8-behind-the-scenes-feb...
However:
* until ignition is not available by default on Node.js (now only through the --ignition flag, or using current master), a lot of these optimization tricks will stay up to date. Also, companies have a history of moving slowly to newer versions of Node.js.
* even with ignition (I just tested it), using Generators (including async functions) is an optimization killer.
Currently trying to rewrite the Exp rule from using combinators to using something that'll properly handle operator precedence (Not keen on having 11 levels of operator precedence encoded in the grammar)
Fix your website. Remove those silly icons!
Whether it's share buttons or an email signup...I mean heck, Europe essentially passed a mandatory website popup law for telling you about cookies.
https://www.theregister.co.uk/2017/01/10/brussels_announces_...
- Node upgraded v8 to 5.7 [1] & async functions as fast as promises [2]
- Optimizations in fs[3]
[1] https://github.com/nodejs/node/pull/11752
[2] https://v8project.blogspot.ca/2017/02/v8-release-57.html
Isn't this something Babel does quite often?
Thanks a lot for your remark!
I'm mostly used to it an class inheritance-related contexts. Is it used differently in the Node/JS-community?
Suggested reading: http://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism.h...
If you love JavaScript we want you to work with us. Drop me a line through my profile.
While these optimizations can be helpful, real problem is order of growth. To optimize order of growth problems knowledge of algorithms and data structures is important.
Optimization can be assisted by instrumentation and profiling.
That's pretty obvious. An engine's optimization features are there to help execute code faster, not as a substitute for knowledge about algorithms and data structures. The implication here is that being respectful of both solid CS theory and an engine's optimized patterns allows you to benefit from both, not just one or another.
I ignored them, ran a profiler, found a bottleneck and fixed the bottleneck.
Sounds obvious but not everyone is familiar with performance optimization.
Not trying to invalidate the fact that you found a way to enhance performance via profiling - that's great! But the way you phrased your response seemed very condescending of "people" when there may have been truth to what they said.
Regarding performance of node.js applications I often find myself looking at my cpu profiles and memory dumps in node-inspector because the most common problems are eventloop starvation, memory leaks or long GC pauses.
What does this mean? I don't understand if it's good or bad. Sounds bad but seems good according to the table?
The concept of non-optimization is describbed in my previous article: https://community.risingstack.com/how-to-find-node-js-perfor...
tl;dr: you want to avoid patterns that prevent optimization: the ones with a red "no" in the table.
It blows my mind to encounter this bad practice on a developper related website.
getEventListeners(window).wheel[0].remove()I tried in Chrome (56.0.2924.87) and Firefox (forgot what version and now it's updating). Firefox doesn't even respond to `getEventListeners` and in Chrome I'm seeing `.scroll` instead of `.wheel`.
window.addEventListener('scroll', function(evt) { evt.stopImmediatePropagation(); }, true)Any idea how much potential that snippet has for causing issues if applied generally across the board?
https://chrome.google.com/webstore/detail/disable-scroll-jac...