“Clean” Code, Horrible Performance

Re:“Clean” Code, Horrible Performance by fvdessen on Tuesday February 28, 2023 @05:02PM (#34975554)

I once optimised a SPA app that had to be really fast for usability reasons (industrial use), I replaced all the 'high level' JS patterns such as map, filter, and frontend framework things to use just if else and for loops and native dom manipulation, and it ended up more than 10x faster, each click would update the app in one frame, it was very noticeable. So yes CPU cycles do matter for websites, even with modern hardware. However the code was more verbose and needed a lot more technical know-how to understand and maintain.

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by Veliladon on Tuesday February 28, 2023 @06:22PM (#34976388)

Yep. In Rust land for instance it'd get compiled down to a for loop and be ridiculously fast. Every time you do a .map or a .filter in JS though it gets abstracted down to a function that makes an allocation for the ENTIRE ARRAY and then copies the entire array into that new array doing whatever you asked to data. The JS VM might be able to optimize some of it away but the abstraction is awful.

So if you were to manually run a for loop over an array instead of iterating through it I'm not surprised you got an order of magnitude faster performance.

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by gardenhedge on Tuesday February 28, 2023 @06:54PM (#34976670)

I'd be interested in a blog post on this. Why is JS map so much slower than a for loop?

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by Veliladon on Tuesday February 28, 2023 @08:19PM (#34977500)

So normally when you do a bunch of patterns of .filter(), and/or .map(), and/or .reduce() on an array in most other languages the compiler will normally iterate through the elements doing whatever you requested at each element. No allocations, one quick trip through the entire working set, cache locality works no matter how big the set is.

In JavaScript on the other hand it handles the abstraction by constructing a separate function for each pattern you use. In those functions it allocates an array the same size as the working set, iterates through each element, then returns the new array. If you're doing multiple operations at once this means that you have to have multiple allocations and multiple iterations through the entire working set.

Because it's doing an allocations it's basically doing an extra memcpy for each additional pattern past one which is a giant slowdown. Then if the working set is too big for the L2 cache it needs to be reloaded from L3 each loop. If the working set is too big for L3 then it needs to reload from main memory EACH TIME.

If you wanted to implement patterns as slow as molasses I can think of no better way than to sugar it out like JavaScript did.

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by jimbokun on Tuesday February 28, 2023 @10:02PM (#34978250)

Interesting. Is there something about JS semantics that prevents JS engine writers from better optimizing that pattern?

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by Veliladon on Wednesday March 01, 2023 @12:46AM (#34979189)

Short answer: JavaScript arrays are sparse and untyped.

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by david2ndaccount on Tuesday February 28, 2023 @08:33PM (#34977609)

Approximately, the slowest thing you can do in a program is memory allocation (and garbage collection is even slower). JS map allocates an entire new array.

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by jimbokun on Tuesday February 28, 2023 @09:59PM (#34978232)

Interesting that the speed up you saw was very similar to what the author got from the same kind of changes in C++.

[ Parent | on HN ]