Post: Performance issues you don't need to fix

[kettanaito]

Performance concern is essential. However, people often dive into pre-mature performance-based decisions without a) monitoring, b) assessing the problem, c) solving the issue on the proper level.

This topic has been inspired by a Twitter discussion, where the usage of .map().filter() was stated as "harmful". One of the argumentations was performance. I find this statement farfetched and misleading. I generally see a lot of the idea that "X is better than Y" for performance on the Internet. I wish to dispel the myth that one/two/ten small API decisions are crucial for performance. It's not.

First, I'd like to speak about 2 types of performance:

1. Architectural performance.
2. Runtime performance. Affected by infrastructure, caching, CDN, transfer protocol, and then front-end build quality (compression, dead code elimination), and only then if you write the code effectively (and even then it's not about low-level API anyway, but rather about architectural decisions).

Key points I wish to convey:

1. Don't optimize for performance if you don't have an issue.
2. Don't think that for is faster than .map. Don't trust synthetic performance benchmarks. Trust in O(n).
3. Suggestions what does affect performance, and how you can make safe decisions without limiting yourself, or creating pointless obscure guidelines.
4. Choices like for vs map may have an effect when processing huge (and I mean HUGE) data. Be honest with yourself: are you processing such data? Then don't expect that choice to have any effect on your performance.

Quotes

If it's not broken, don't fix it.

Assuming that front-end is the reason for poor performance is like assuming a dash panel to be the cause of a slow vehicle. Just because front-end is the primary surface of experiencing the issue, doesn't mean it is the issue.

Basing your coding style and API choices around performance is, well, bad.