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.

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.

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

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.

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

Short answer: JavaScript arrays are sparse and untyped.

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.

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

I just loaded cnn.com while looking at the CPU utilization graph: 50% use of my 8 logical cores at 4.5GHz for the better part of a second. So no, it's not just network latency. Doing multiple parallel network requests, parsing, doing layout and applying styles, running scripts, decoding media... a modern website and browser devours CPU time.

Jira cloud famously takes 30-60 seconds on even a fairly high-end laptop, which is just staggering. I can install an entire operating system into a virtual machine in that time.

> Jira cloud famously takes 30-60 seconds on even a fairly high-end laptop,

I use Jira every day and, no, it does not take 30-60 seconds to load a page.

The hyperbole in this comment section is something else. Either that or people are using 15 year old computers to browse the web.

I see 30-seconds delays in a vanilla project on Jira cloud sometimes. Hardware was expensive in 2019.

AdBlocker on or off?

lite.cnn.com

So those who visit Fox and CNN are helping to destroy the planet. Or is it the developers fault? Can't be the developers.

one of them must be to blame! readers and publishing engineers famously sit atop corporate decision-making hierarchies, and no one else in a mass media enterprise ever did anything wrong, certainly not before the web was a thing

I was about to dispute what you said, but I realised I was running uBlock origin. What machine and browser are you using? I just used Chrome (on MacOS using an M1 Pro CPU) to run a performance profile and loading cnn.com took the following:

- Loading: 29ms with uBlock vs 42ms without

- Scripting: 548ms vs 1850ms (!!)

- Rendering: 42ms vs 105ms

- Painting: 8ms vs 29ms

- System: 216ms vs 295ms

- Idle: 460ms vs 8707ms

Holy shit, advertising and trackers are absolute resource hogs.

This might hold true if you’re talking about desktop browsers, but it’s a different story on mobile, particularly in rapidly growing emerging markets. Both network latency and large JS payloads dramatically affect user experience on low powered devices, and if UX isn’t compelling enough, there have been plenty of studies showing the real financial costs of slow web pages for businesses that depend those websites to bring in customers.

I’ve personally spent many hours doing performance analysis, triage and remediation on websites built using modern tech stacks that had inadvertently exchanged UX for DX. Too much JS sent over the wire can definitely tie up the browser’s main thread for whole seconds even on desktop, though in my experience it’s much more common on mobile. This situation can be difficult to correct depending on the abstractions, organization and overall architecture you chose early on, and code-spitting and dead code elimination won’t always fix what’s broken.