const evenItems = arr = arr.filter((_, index) => index % 2 === 0);
Returns an array which contains every even item of the original array.
The repository & npm package
You can find the all the utility functions from this series at github.com/martinkr/onelinecode
The library is also published to npm as @onelinecode for your convenience.
The code and the npm package will be updated every time I publish a new article.
Follow me on Twitter: @martinkr and consider to buy me a coffee
Photo by zoo_monkey on Unsplash
Top comments (16)
Or you use the fastest possible version:
I mean, you could just use a
filter, which is faster and from my point of view is also more readable:Cheers!
+1 for this. I'll always prefer legible over performant unless dealing with code that absolutely requires performance. 99% of the time I'm dealing with small datasets so it isn't necessary. And as you've said below, v8 optimises a lot of these convenience methods.
I would have thought filter was indeed slower, but not according to this.
It is one of the cases where performance really depends on the browser / javascript engine.
Agreed.
I tested it w/ Chrome, on Mac & Linux. Not sure how Safari / Firefox results may vary.
Hi Luke,
you are right filter is more intuitive, but it is actually slower for me.
Cheers!
No, it isn't faster. Not sure what's wrong with your machine, but it's about 20-30% slower on any machine I tested it on.
Hey!
thank you for taking the time to contribute, I put both functions to the performance benchmark on hasty and I'm going to update the article with your suggestion!
Cheers!
You forgot to run the code in that benchmark, so you're only testing the declaration of both functions, not the actual function running ... here you have an actual comparison. With filter it is faster.
Hi Luke,
yes you are right :D Here is the updated benchmark on hasty - filter is much slower for me.
Try moving the funciton declarations to the global block (you only need to declare them once and then run them). Maybe is slower in non-chromium browsers, I'm testing on Chrome.Edit: Tried it in Safari and performance sucks there. Chromium makes optimizations in this kind of algorithms that other browsers don't. From a logic stand point the
forapproach effectively should run in half the time because is skipping the odd indexes instead of filtering them. Still I would prefer that other browsers optimize my code as Chromium does so I can write simple code and it gets optimized for me.I just ran that test and for was 20% faster on current Chrome.
For me too. Chromium based browsers are faster with filter.
Appreciate the discussion. Going to use the filter version as I expect the other browsers / javascript engines to catch up in microoptimisations.
Then at least use
&instead of%if you care about performance. That difference can't be microoptimized, because the modulo requires float point handling, whereas the binary operation runs directly on the CPU.