9 ms·

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high performance calculation software then sure, go crazy, get those improvements. That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time, and indeed, that's often because of the exact kind of overabstraction that this article criticizes (e.g. people use React and then design React component hierarchies that seem "conceptually clean" instead of ones that perform a rendering strategy that makes sense.)

PragmaticPulp 4y ago
> 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.
rodrigobellusci 4y ago
Since you bring up React in your example, which framework should one use to build better performing web apps? I know React tends to lack in both dev UX and performance (at least in my exp). Personally I've taken a look at Svelte and Solid, and liked them both. I haven't had the chance to build anything larger than a toy app, though.
- antoineMoPa 4y ago
  Vue could also be an option, but I personally want to learn some Solid, as I see it could be preferred by the current mass of React frontend developers, more than Svelte and Vue. The syntax and philosophy of Solid looks closer to React, while having a stronger focus on performance.
  - bcrosby95 4y ago
    Okay, I'll bite: does Vue perform better than React? Your post makes no mention of this, I don't know if it does, and offering it as an alternative due to performance reasons, without knowing this, seems a tad premature.
    - antoineMoPa 4y ago
      In my personal experience, the Vue apps I've worked on have been snappier. There are some fast React apps out there, but I think a lot of work goes into optimizing React apps, versus Vue being pretty fast by default. When react introduced hooks, it was fun for a while, but then we discovered the frequent re-render issues and had to change the way we think when building components and refactor old components. We have to manually wrap components in useMemo. This is the kind of things Vue has avoided me so far and React let me down. React relies on running all render methods instead of doing granular updates, I think this hurts performance. Vue listens to property changes and can perform granular updates.
      - antoineMoPa 4y ago
        I kind of want to amend that! I discovered today that maybe there is hope with granular update libraries such as Jotai, @preact/signals-react and recoiljs.
mabbo 4y ago
I don't disagree that the balance is shifting towards "why is this taking so long". There's ebbs and flows in that ecosystem. But overall, I think you overestimate how much time you spend loading the website and how much time it's just sitting there, mostly idle. And in the end, as long as it's fast enough that users don't stop using the site/webapp/program/whatever, then it's fine, imho. When it becomes too slow, the developers will be asked to improve performance. Because in the end, economics is the driver, not performance.
- jstimpfle 4y ago
  And depending on what you do, economics will let performance decide who wins. Git is probably one example. A different example, have you ever compared battery lifes of smartphones before buying one?
- ilyt 4y ago
  > But overall, I think you overestimate how much time you spend loading the website and how much time it's just sitting there, mostly idle. reading the website is productive. Waiting on it to load is not. I'd rather have app burn a whole core whole time if it cut 1s off load time when clicking something.
  - tharkun__ 4y ago
    I think the point would be: what if instead of using a whole core and it takes 2000ms to load because it is essentially "spinning its wheels" it would only use half a core and it takes 50ms? 2s you notice as a user. 50ms you won't. In fact even 500ms you won't notice too much but we are getting close to where optimization will be noticeable to a user.
- sirmarksalot 4y ago
  As an end user, I would prefer to live in a world where I don't have to wait for software to respond. If forced to, I would also continue to use software where I do have to wait. Your argument that economics will dictate the best solution and lead to a happy balance doesn't work. It will tend towards a borderline tolerable world, where your product only has to be better than the other guy's. This is separate from the discussion about tradeoffs between flexible design patterns and low-level performance.
commandlinefan 4y ago
Well, you can make things run even faster by hand-coding it in assembler... but performance isn't the reason we use high level languages. I agree with you that ignoring performance characteristics in favor of speed-to-market is an awful and pervasive practice in modern software development, but the linked article isn't talking about or making that case at all. He's saying that he can make his own custom object oriented C language that runs faster than C++ itself, but that's not news - people were saying that in 1995 (at least). The maintainability hit isn't worth it.
- pmarin 4y ago
  This is not his own custom object oriented C language, this is just a very well known idiom for implementing polymorphic functions in C.
- rerdavies 4y ago
  It's not really possible to write hand-coded assembler that's faster anymore. C/C++ compilers have deep knowledge of architecture-specific instruction pipelines that allow them to schedule instructions more accurately than any human could. My most recent misadventure: trying to write hand-coded ARM Neon assembler, and/or C++ code with neon intrinsics to optimize a piece of real-time audio effect code. The clear performance winner: plain C++ with no intrinsics, but tweaked to allow auto-vectorization (plus judicious use of the __restrict modifier for a small but significant boost). GCC produced code that had better instruction scheduling than I could (but not for the NEON intrinsics, oddly). And as an added bonus, the same plain-old C++ code generates AVX vectorization on MSVC without modifications! (MSVC also supports __restrict until the C++ standards committee gets their act together to adopt the eminently necessary C99 restrict keyword).
  - DeathArrow 4y ago
    It is. I witnessed it many times on Code Golf substack.
  - pg314 4y ago
    >It's not really possible to write hand-coded assembler that's faster anymore. That is wrong. Just because you didn’t succeed in writing faster code in one case, doesn’t mean it’s impossible. See e.g. [1] on why the Lua vm is written in assembly. It’s from 2011 but not much has changed in the meantime. [1] http://lua-users.org/lists/lua-l/2011-02/msg00742.html http://lua-users.org/lists/lua-l/2011-02/msg00742.html
onion2k 4y ago
For what it's worth, less than 4% of websites use React (approximately 4% use any JS framework) . If you believe the web is slow because of React you are wrong. It's not even due to JS.
- gratitoad 4y ago
  I’m curious, where do you get those numbers from? Those are shockingly low numbers and don’t align with my observations, but I also don’t have hard figures to back them up.
- valzam 4y ago
  4% of what? I would wager a guess that close to 100% of Alexa top 1000 websites us a JS framework and a significant portion of that something heavy like React or Angular.
- ramesh31 4y ago
  >It's not even due to JS. Oh it definitely is. But no single framework (or frameworks) are to blame. It's the CMS. The thing that allows every Tom, Dick, and Harry at the company to drop their little snippet for this or that which adds up to a mountain of garbage over time, half of which is disused or forgotten.
- deleted 4y ago
  [deleted]
- jimbokun 4y ago
  Is that weighted for the traffic those web sites receive? It could be that most of the traffic is served by websites using heavyweight frameworks, but the long tail of low traffic websites use them rarely.
- wellanyway 4y ago
  > It's not even due to JS. Do enlighten us then, what is it due to?
simplotek 4y ago
> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...) You attempted to present an argument that's a textbook example of an hyperbolic fallacy. There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time". This blend of specious reasoning is the reason why the first rule of software optimization is "don't". Proponents of mindlessly going about the 1% edge cases fail to understand that the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing, with a tradeoff of producing unmaintainable code. The truth of the matter is that in 99% of the cases there is absolutely no good reason to run after these relatively large performance improvements if in the end the user notices absolutely nothing. Moreso if you're writing async code that stays far away from any sort of hot path.
- heisenbit 4y ago
  How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?
  - eropple 4y ago
    In my experience: a profiler, usually. Just because I can throw down a lot of code quickly doesn't mean I don't have the tools to analyze code when I go "hmm, that seems slow".
    - incrudible 4y ago
      That works for big hotspots, but not for the tiny papercuts that make every little thing 10x slower.
      - eropple 4y ago
        Sure. That's a tradeoff you consciously make to get the thing out the door. That's what technical debt is. You pay it down later. (Or you go bankrupt and it doesn't matter anymore.)
WatchDog 4y ago
Most of these websites have neither clean code nor hyper optimisation, just bad code all round.

PragmaticPulp 4y ago

> 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.

rodrigobellusci 4y ago

Since you bring up React in your example, which framework should one use to build better performing web apps? I know React tends to lack in both dev UX and performance (at least in my exp). Personally I've taken a look at Svelte and Solid, and liked them both. I haven't had the chance to build anything larger than a toy app, though.

antoineMoPa 4y ago
Vue could also be an option, but I personally want to learn some Solid, as I see it could be preferred by the current mass of React frontend developers, more than Svelte and Vue. The syntax and philosophy of Solid looks closer to React, while having a stronger focus on performance.
- bcrosby95 4y ago
  Okay, I'll bite: does Vue perform better than React? Your post makes no mention of this, I don't know if it does, and offering it as an alternative due to performance reasons, without knowing this, seems a tad premature.
  - antoineMoPa 4y ago
    In my personal experience, the Vue apps I've worked on have been snappier. There are some fast React apps out there, but I think a lot of work goes into optimizing React apps, versus Vue being pretty fast by default. When react introduced hooks, it was fun for a while, but then we discovered the frequent re-render issues and had to change the way we think when building components and refactor old components. We have to manually wrap components in useMemo. This is the kind of things Vue has avoided me so far and React let me down. React relies on running all render methods instead of doing granular updates, I think this hurts performance. Vue listens to property changes and can perform granular updates.
    - antoineMoPa 4y ago
      I kind of want to amend that! I discovered today that maybe there is hope with granular update libraries such as Jotai, @preact/signals-react and recoiljs.

mabbo 4y ago

I don't disagree that the balance is shifting towards "why is this taking so long". There's ebbs and flows in that ecosystem. But overall, I think you overestimate how much time you spend loading the website and how much time it's just sitting there, mostly idle. And in the end, as long as it's fast enough that users don't stop using the site/webapp/program/whatever, then it's fine, imho. When it becomes too slow, the developers will be asked to improve performance. Because in the end, economics is the driver, not performance.

jstimpfle 4y ago
And depending on what you do, economics will let performance decide who wins. Git is probably one example. A different example, have you ever compared battery lifes of smartphones before buying one?
ilyt 4y ago
> But overall, I think you overestimate how much time you spend loading the website and how much time it's just sitting there, mostly idle. reading the website is productive. Waiting on it to load is not. I'd rather have app burn a whole core whole time if it cut 1s off load time when clicking something.
- tharkun__ 4y ago
  I think the point would be: what if instead of using a whole core and it takes 2000ms to load because it is essentially "spinning its wheels" it would only use half a core and it takes 50ms? 2s you notice as a user. 50ms you won't. In fact even 500ms you won't notice too much but we are getting close to where optimization will be noticeable to a user.
sirmarksalot 4y ago
As an end user, I would prefer to live in a world where I don't have to wait for software to respond. If forced to, I would also continue to use software where I do have to wait. Your argument that economics will dictate the best solution and lead to a happy balance doesn't work. It will tend towards a borderline tolerable world, where your product only has to be better than the other guy's. This is separate from the discussion about tradeoffs between flexible design patterns and low-level performance.

commandlinefan 4y ago

Well, you can make things run even faster by hand-coding it in assembler... but performance isn't the reason we use high level languages. I agree with you that ignoring performance characteristics in favor of speed-to-market is an awful and pervasive practice in modern software development, but the linked article isn't talking about or making that case at all. He's saying that he can make his own custom object oriented C language that runs faster than C++ itself, but that's not news - people were saying that in 1995 (at least). The maintainability hit isn't worth it.

pmarin 4y ago
This is not his own custom object oriented C language, this is just a very well known idiom for implementing polymorphic functions in C.
rerdavies 4y ago
It's not really possible to write hand-coded assembler that's faster anymore. C/C++ compilers have deep knowledge of architecture-specific instruction pipelines that allow them to schedule instructions more accurately than any human could. My most recent misadventure: trying to write hand-coded ARM Neon assembler, and/or C++ code with neon intrinsics to optimize a piece of real-time audio effect code. The clear performance winner: plain C++ with no intrinsics, but tweaked to allow auto-vectorization (plus judicious use of the __restrict modifier for a small but significant boost). GCC produced code that had better instruction scheduling than I could (but not for the NEON intrinsics, oddly). And as an added bonus, the same plain-old C++ code generates AVX vectorization on MSVC without modifications! (MSVC also supports __restrict until the C++ standards committee gets their act together to adopt the eminently necessary C99 restrict keyword).
- DeathArrow 4y ago
  It is. I witnessed it many times on Code Golf substack.
- pg314 4y ago
  >It's not really possible to write hand-coded assembler that's faster anymore. That is wrong. Just because you didn’t succeed in writing faster code in one case, doesn’t mean it’s impossible. See e.g. [1] on why the Lua vm is written in assembly. It’s from 2011 but not much has changed in the meantime. [1] http://lua-users.org/lists/lua-l/2011-02/msg00742.html http://lua-users.org/lists/lua-l/2011-02/msg00742.html

onion2k 4y ago

For what it's worth, less than 4% of websites use React (approximately 4% use any JS framework) . If you believe the web is slow because of React you are wrong. It's not even due to JS.

gratitoad 4y ago
I’m curious, where do you get those numbers from? Those are shockingly low numbers and don’t align with my observations, but I also don’t have hard figures to back them up.
valzam 4y ago
4% of what? I would wager a guess that close to 100% of Alexa top 1000 websites us a JS framework and a significant portion of that something heavy like React or Angular.
ramesh31 4y ago
>It's not even due to JS. Oh it definitely is. But no single framework (or frameworks) are to blame. It's the CMS. The thing that allows every Tom, Dick, and Harry at the company to drop their little snippet for this or that which adds up to a mountain of garbage over time, half of which is disused or forgotten.
deleted 4y ago
[deleted]
jimbokun 4y ago
Is that weighted for the traffic those web sites receive? It could be that most of the traffic is served by websites using heavyweight frameworks, but the long tail of low traffic websites use them rarely.
wellanyway 4y ago
> It's not even due to JS. Do enlighten us then, what is it due to?

simplotek 4y ago

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...) You attempted to present an argument that's a textbook example of an hyperbolic fallacy. There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time". This blend of specious reasoning is the reason why the first rule of software optimization is "don't". Proponents of mindlessly going about the 1% edge cases fail to understand that the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing, with a tradeoff of producing unmaintainable code. The truth of the matter is that in 99% of the cases there is absolutely no good reason to run after these relatively large performance improvements if in the end the user notices absolutely nothing. Moreso if you're writing async code that stays far away from any sort of hot path.

heisenbit 4y ago
How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?
- eropple 4y ago
  In my experience: a profiler, usually. Just because I can throw down a lot of code quickly doesn't mean I don't have the tools to analyze code when I go "hmm, that seems slow".
  - incrudible 4y ago
    That works for big hotspots, but not for the tiny papercuts that make every little thing 10x slower.
    - eropple 4y ago
      Sure. That's a tradeoff you consciously make to get the thing out the door. That's what technical debt is. You pay it down later. (Or you go bankrupt and it doesn't matter anymore.)

WatchDog 4y ago

Most of these websites have neither clean code nor hyper optimisation, just bad code all round.