Hacker News Reader

Comment by frandroid | Hacker News Reader

An amusing tidbit about optimization, toward the end:

> Because we were seeking to improve performance, we became interested in benchmarking upgrades to major dependencies. While your mileage may vary, upgrading from Node 4 to Node 6 decreased our response times by about 20%. Upgrading from Node 6 to Node 8 brought a 30% improvement. Finally, upgrading from React 15 to 16 yielded a 25% improvement. The cumulative effect of these upgrades is to more than double our performance, and therefore our service capacity.

Free optimization, ripe for the taking!

View on HN

Depending on the code and the dependencies it might not be that free if you run on some unexpected problems after those upgrades due to some incompatibilities or even reliance on now-fixed bug. While I understand that the latter should not be the case given the code is written properly but with sufficiently large projects this is not as uncommon as we would like it to be.

Also there is a more common scenario where updating one thing requires updating other packages and through a long chain of denependencies one of the pieces being updated has something missing in the new version (that was available in the previous version) and anything that relies on that will stop working.

Anyway, even the best case scenario where everything is perfectly fine after the updates still requires detailed testing to ensure that really everything is as OK as it seems. So even then this is not totally free

But then of course, it may still be the easiest path for improving the performance.

> easiest path for improving the performance.

upgrading should not be seen as an alternative to performance engineering though. Even if upgrading _does_ bring in some performance improvements.

Upgrading should be because of reasons such as security updates, and bug-fixes, and to continue to reap the improvements/features in the next version.

No, not an alternative, but I'd argue that considering new versions should be a part of performance engineering. If one of the "improvements/features in the next version" is more optimized and performant code, you want to "reap" it (after of course considering and testing the upgrade from other points of view.

Reply on news.ycombinator.com