4 ms·

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time Unless we’re talking about spe

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time Unless we’re talking about specific compute-intensive websites, this is almost certainly network loading latency. Modern web browsers are very fast. Moderns CPUs are very fast. Common, random websites aren’t churning through “multiple seconds” of CPU time just to render.

fvdessen 4y ago
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.
- Veliladon 4y ago
  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.
- gardenhedge 4y ago
  I'd be interested in a blog post on this. Why is JS map so much slower than a for loop?
  - Veliladon 4y ago
    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.
    - jimbokun 4y ago
      Interesting. Is there something about JS semantics that prevents JS engine writers from better optimizing that pattern?
      - Veliladon 4y ago
        Short answer: JavaScript arrays are sparse and untyped.
  - david2ndaccount 4y ago
    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.
- jimbokun 4y ago
  Interesting that the speed up you saw was very similar to what the author got from the same kind of changes in C++.
gary_0 4y ago
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.
- datavirtue 4y ago
  So those who visit Fox and CNN are helping to destroy the planet. Or is it the developers fault? Can't be the developers.
  - replygirl 4y ago
    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
- gowld 4y ago
  AdBlocker on or off?
- smoyer 4y ago
  lite.cnn.com
- jiggawatts 4y ago
  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.
  - PragmaticPulp 4y ago
    > 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.
gratitoad 4y ago
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.

fvdessen 4y ago

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.

Veliladon 4y ago
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.
gardenhedge 4y ago
I'd be interested in a blog post on this. Why is JS map so much slower than a for loop?
- Veliladon 4y ago
  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.
  - jimbokun 4y ago
    Interesting. Is there something about JS semantics that prevents JS engine writers from better optimizing that pattern?
    - Veliladon 4y ago
      Short answer: JavaScript arrays are sparse and untyped.
- david2ndaccount 4y ago
  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.
jimbokun 4y ago
Interesting that the speed up you saw was very similar to what the author got from the same kind of changes in C++.

gary_0 4y ago

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.

datavirtue 4y ago
So those who visit Fox and CNN are helping to destroy the planet. Or is it the developers fault? Can't be the developers.
- replygirl 4y ago
  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
gowld 4y ago
AdBlocker on or off?
smoyer 4y ago
lite.cnn.com
jiggawatts 4y ago
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.
- PragmaticPulp 4y ago
  > 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.

gratitoad 4y ago

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.