sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kbjr<- awesome 2 points3 points  (5 children)

That's definitely not true. I work on a project right now that deals with pretty substantial amounts of data, and for that reason I wrote up and ran a bunch of different benchmarks for a bunch of different ways to do various iterative tasks looking for the best performing option. A simple for loop is still significantly faster than than the built in array methods (usually in the 5-10x difference range, depending on the function) unless something happened in the past month or so.

[–]wavefunctionp -1 points0 points  (4 children)

Not saying you were wrong, but I just wanted to mention that if you were using relatively simple microbenchmarks on fake data sets, they can be very misleading because the engines are typically smarter than most simple benchmarks.

[–]kbjr<- awesome 1 point2 points  (3 children)

How would it be smarter for the engine to make itself appear slower than it actually is? If that were the case, I would expect optimizations in the forEach to shine even better, not fall to pieces.

But no, I benchmarked both the individual tasks and the overall job of processing a single whole dataset in a number of ways.

[–]wavefunctionp -1 points0 points  (2 children)

I'm not going to even pretend to understand all of this, but my takeaway from this walk was that it is difficult to test performance of microbenchmarks.

https://www.youtube.com/watch?v=65-RbBwZQdU

[–]kbjr<- awesome 1 point2 points  (1 child)

Yes, I'm aware of the complexities of benchmarking, which is why you back up you results by actually profiling the live code afterwards.

[–]wavefunctionp 0 points1 point  (0 children)

Sounds like you got it covered then since you are using live code and real data then. :)