Performance matters: the story of a nice JavaScript refactoring

Days ago I was pleasantly surprised by a contribution that a friend of mine ilteoood made to the Orama repository. The post said:

Performance improved by 5%!

I thought, damn, some good developers were working there at Orama, so who knows how he managed to improve the code so much. In a world where everything runs on the cloud, we must take into consideration that an improvement of this type is not a given Faster calculations mean a reduction in costs and therefore a real advantage for the company.

Over the years I have learned to know myself and I must say that I love to delve into things when the topic interests me. So once again I stopped scrolling through LinkedIn feeds and took the time to check the PR. And I saw some interesting things that still stick with me today, after a few weeks away.

While benchmarks should always be taken with a grain of salt, it is clear in this example that code where the calculation of `.length` is done only once is faster even if the code is really simple.

If I have made you curious about the other changes that the good ilteoood has made, here is the PR

I hope you liked the article, see you next time.

While benchmarks should always be taken with a grain of salt, it is clear in this example that code where the calculation of `.length` is done only once is faster even if the code is really simple.

Comment on LinkedIn

Did you like this content?

While benchmarks should always be taken with a grain of salt, it is clear in this example that code where the calculation of .length is done only once is faster even if the code is really simple.

Comment on LinkedIn

Did you like this content?

While benchmarks should always be taken with a grain of salt, it is clear in this example that code where the calculation of `.length` is done only once is faster even if the code is really simple.