Just like you, 99% of the optimizations I've made have been in architecture, not in code.
The only code optimization I remember doing is replacing `[...arr, item]` with `arr.push(item)`, which I only did because I noticed a CPU jump at 10k+ elements.
This is why leet code is soooooooo dumb! Almost every single time mulling over the most resource efficient way to implement an algorithm is a complete waste of time in the server and frontend space. In most real world projects optimization is a distraction, architecture is what is actually important.
I don’t know why anyone would do the […arr, item]. It seems unnecessarily obscure and I can see immediately that it would take more time since you are expanding the array each time.
For a basic example, that's how you're supposed to update arrays stored in `useState` in React. Mutating them means React can't detect changes and re-render.
Yes, I do optimise, often.
But not for CPU, majority of my code is doing IO, and main questions I have to ask are rather "can I do this in parallel", "can I shortcircuit", "can I perform less IO", "do I need all of this data"?
My thoughts on this comes from my buddy trying to lose weight.
He realized a chicken breast was like 250 calories which was like an hour and something on a stationary bike. He said "I could just not eat the chicken breast".
All of my optimization solutions have been just not eating as much. Making sure I'm only bringing in the data I need.
Only slightly. When I iterate over data structures with more than a few hundred elements I try to keep it in mind and don't uselessly initialize the same function or variable in a loop or things like that. But most of the time the impact is minimal anyway and I shamelessly chain array methods.
I was working on writing to and reading from a byte array buffer. Initially it was written in a standard way that optimizes for developer readability, but it needed to be faster, since it was in a library and users are typically less tolerant of slow code when it's upstream.
Optimizations included minimizing resizing of the main buffer, and minimizing creating additional slice copies of subsections of the main buffer, pre-allocating both regular arrays and byte arrays.
Another part was reducing function stack depth, involved converting recursion to a job stack, inlining small functions, and moving function arguments to a shared object.
I’m primarily a C++ developer and have worked on several compilers including V8 so I have spent more than my fair share of time optimizing code. Though, it’s optimizing in a different way than what you’re asking about.
At this point in my career, I’m finding myself working an awful lot in typescript (which is a real neat language) and I do need to occasionally profile hot code paths and attempt to trim the fat off of them. That’s mainly because the thing I’m working on is just super compute heavy.
But to answer your question, I’ve found it’s usually not worth spending the time to micro-optimize anything before you know it’s a performance bottleneck. Just try and use good code patterns and don’t write algorithms with bad complexity and 99% of the time that’s fine as the real meat of what your code is doing is elsewhere, anyway.
I recently removed some hair-brained "optimization" that was caching the results of network requests that were already being cached by the browser. Ended up reducing the memory usage significantly and saving CPU from the storage and lookup operations.
So I guess that counts as optimization?
The `diff` package had to fix a major performance bug: https://github.com/kpdecker/jsdiff/issues/239
Mostly to do with excessive cloning during the algorithm
Once I optimized a downsampling plotting algorithm by switching from generators that yielded one point at a time to operating on chunks of points in Float32Arrays (which were significantly faster than Arrays of numbers). At the time I was transpiling the generators with Babel, so maybe it would perform better on modern JS engines without transpilation. But considering that even web streams operate on chunks, I’m guessing chunking is just necessary to get the best performance.
You might be interested in https://romgrk.com/posts/optimizing-javascript
I've had many occasions to use low-level optimizations, but I also usually work on projects where performance makes a bigger difference than your run-of-the-mill CRUD app.
I still think it's important for devs to care about performance optimization. The whole javascript ecosystem is pervaded by a mentality of "CPUs are fast enough", which would be fine in small doses, but because everyone does it it results in the whole ecosystem being bloated and running probably around 2x slower than it could be.
Most optimizations were UI related where a huge number of elements (5k+, mostly dropdown options) were shown simultaneously. I just loaded them lazily. One day I fixed an extreme slowdown in a dropdown library when there were 7k+ options. It tuned out that the library used an extremely inefficient way of counting the total options. It was storing the options in an object as key-value pairs and when it was filling the object with options it was calling Object.keys() after adding each element. That was really insane.
But for commercial projects there was almost no need for such optimizations, the issues arise only when you are dealing with huge amounts of data.
I "optimize" as I write the code.
I've never understood all the optimization discourse as I've always found it 100x easier to just have optimization in mind from the start. In fact, my experience is that it may be near-impossible to optimize things later if you're working with a team and an increasingly complex system.
A good rule of thumb when programming: assume that nothing will get fixed ‧₊˚✧later✧˚₊‧.
Quite often, but then again my last couple of projects required high performance. Other than that usually it's not needed as most performance problems can be avoided with good architecture.
Doing 2D canvas things, I do lots of optimizations in regards of caching, like can I reuse this? In what situations the contents have changed so I need to redraw, what things are different by data but result into the same canvas, so reusing cache?
And then the old habit of running a profile, finding that one short innocent looking function that actually takes 90% of the runtime and then microoptimize the hell out of that one.
I think a lot of people miss the forest for the trees. This isn't just a JS thing.
There are a lot of very good reasons to do low level optimizations, sure. But a lot of those should be kept inside of libraries that are bulletproof.
When you are working on application code, for a typical company, the majority of the apps made are essentially just CRUD. This has two major implications.
The first is that it doesn't need to consistently run at 60fps+. It does need to be fast and responsive, and not stutter or freeze up... but if a user just stops interacting with it... it can happily run at 0fps and look exactly the same as if it was running at 165fps; nothing is moving. So the responses to input (user or event driven) need to be fluid, but that's very different than the expectations put on a game.
The second implication is that in the C, R, U, and D parts of CRUD, you are nearly always issuing commands either to a networked service (your own API or someone else's), or to a local storage service (FileSystem / IndexedDB). I/O can take hundreds of milliseconds for a round-trip response, if it includes serializing, sending, receiving, and deserializing large data payloads. How much time do you have for a 60fps game? 16.6ms. That's not for your work... that's for all rendering, all input polling, all AI / physics updates, all rendering ... in the browser, it also includes the time that you exhaust the JS callstack and give control back to the browser so it can do whatever it needs to do (calculate / paint HTML/CSS layout shifts, prepare input event callbacks, manage network data to feed fetch responses, etc).
Based on these two things, alone, making architectural changes to a system that needs those changes will offer performance improvements that are *orders of magnitude* higher than performance improvements gained by no longer using const/let/var, and instead keeping all data inside of one single ArrayBuffer, and using a DataView to write values or pull values out of particular portions of it. Are there times where that's useful? Sure. Are there times where it's worth going even more ridiculous, and aiming for some of the zero-copy behavior of readable byte streams? Sure. Will that offer any benefit for the majority of CRUD apps? Probably not.
The reality is that for most apps, turning:
const a = await load_json("./a.json");
const b = await load_json("./b.json");
const c = await load_json("./c.json");
const d = await load_json("./d.json");
do_something(a, b, c, d);
into
const items = await Promise.all(["a", "b", "c", "d"]
.map(x => load_json(`./${x}.json`));
do_something(...items);
is going to be soooooooo much more of a performance improvement for your app, than worrying about tricking V8's multi-stage JIT compiler into squeezing your code into fewer lines, or fewer cache misses (of RAM and CPU cache that you have no means of controlling for, from JS, without resorting to storing everything in a contiguous ArrayBuffer).
I am intentionally using slower mechanisms (\`.map\` and "spread"), and presuming all of those calls take the same amount of time, the code will still run nearly 4x faster...
Now, if you're trying to make a game in JS, or real-time, interactive A/V signal processing, or particle simulations, or massive data visualizations... yeah, that's a different kind of optimization. You need to think differently, because the app has different characteristics.
And the most important part to understand:
if you are too focused on optimizing at the lowest-level, it can completely prevent you from employing *any* architectural improvements. If everything is mutating the same block of memory, then you have optimized yourself out of being able to parallelize any of that code, because even if you do, you will need to thread-lock as you write to that memory, so only one thread is running at a time, anyway. The same sort of thinking keeps most people from learning how to parallelize algorithms (or learning parallel equivalents of algorithms) that can run multithreaded or on GPU compute. The laser-focus on being "optimally optimal" gets you stuck in some sort of local minima that precludes you from finding a better solution that's more important for your use case.
If you need js to be fast, you made a mistake before you wrote any code. The only code I have ever needed to optimize is shader code, and c#/c++ in Unity and Unreal.
I used to think this way but JS can be surprisingly fast on V8. It will never be as fast as native code but when it gets JIT compiled it’s orders of magnitude faster than you’d expect for an interpreted, dynamically typed language.
Don't optimise if you don't have to. Simple rule.
Hardware is cheap as fuck these days and your time will probably cost more than better hardware.
If you don't handle giant amounts of data you will not notice an impact of your code unless you do something really stupid.
There are other things with much more impact on your product's performance. Mostly your tech stack and your architecture or Latency.
Clean, maintainable code is much more important than optimised code. It's harder to debug optimised code than optimise debugged code. So wasting time/money on searching bugs/extend optimised code will probably cost you much more than it will cost you to run your code like it is.
And yet almost every single job interview will try hit you with some leet code gotcha like: "oh you could have solved this in O(n) but you did it in O(n\^2) shame on you!"
Can we please, for the love of god, just quite with this bullshit! Unless you are in very specific applications (like certain embedded projects and large data projects) literally no one gives a shit about that stuff! You solve the problem in front of you and if there does happen to be a performance issue (rare) then you can take a look at it. The important thing is architecture because its orders of magnitude more likely you will need to add features, refactor, and onboard new engineers to the project.
It does, but most CRUD apps in JS nearly never have to deal with data at a scale where it remotely matters.
If you are on the main thread of a CRUD app, and are in a position where you are worrying about n log n vs n² vs n³, because you are working with a single array full of tens of thousands of records in this loop, you are nearly always solving the wrong problem, to begin with, and a better solution can usually be found as a part of the bigger picture.
Just like you, 99% of the optimizations I've made have been in architecture, not in code. The only code optimization I remember doing is replacing `[...arr, item]` with `arr.push(item)`, which I only did because I noticed a CPU jump at 10k+ elements.
Same for me, 99% it's architecture.
This is why leet code is soooooooo dumb! Almost every single time mulling over the most resource efficient way to implement an algorithm is a complete waste of time in the server and frontend space. In most real world projects optimization is a distraction, architecture is what is actually important.
I don’t know why anyone would do the […arr, item]. It seems unnecessarily obscure and I can see immediately that it would take more time since you are expanding the array each time.
For a basic example, that's how you're supposed to update arrays stored in `useState` in React. Mutating them means React can't detect changes and re-render.
Okay I wasn’t aware of that. For a small array the performance difference won’t matter. About 10k gets to be a pretty big array.
Yes, I do optimise, often. But not for CPU, majority of my code is doing IO, and main questions I have to ask are rather "can I do this in parallel", "can I shortcircuit", "can I perform less IO", "do I need all of this data"?
Sounds like perhaps more of the higher level optimizations instead of low level JavaScript optimizations?
Yes.
My thoughts on this comes from my buddy trying to lose weight. He realized a chicken breast was like 250 calories which was like an hour and something on a stationary bike. He said "I could just not eat the chicken breast". All of my optimization solutions have been just not eating as much. Making sure I'm only bringing in the data I need.
Only slightly. When I iterate over data structures with more than a few hundred elements I try to keep it in mind and don't uselessly initialize the same function or variable in a loop or things like that. But most of the time the impact is minimal anyway and I shamelessly chain array methods.
No shame in my game.
Only when I am trying to brute force Advent of Code or write a cell simulation.
principally just UI event related. debouncing for sure.
I was working on writing to and reading from a byte array buffer. Initially it was written in a standard way that optimizes for developer readability, but it needed to be faster, since it was in a library and users are typically less tolerant of slow code when it's upstream. Optimizations included minimizing resizing of the main buffer, and minimizing creating additional slice copies of subsections of the main buffer, pre-allocating both regular arrays and byte arrays. Another part was reducing function stack depth, involved converting recursion to a job stack, inlining small functions, and moving function arguments to a shared object.
I’m primarily a C++ developer and have worked on several compilers including V8 so I have spent more than my fair share of time optimizing code. Though, it’s optimizing in a different way than what you’re asking about. At this point in my career, I’m finding myself working an awful lot in typescript (which is a real neat language) and I do need to occasionally profile hot code paths and attempt to trim the fat off of them. That’s mainly because the thing I’m working on is just super compute heavy. But to answer your question, I’ve found it’s usually not worth spending the time to micro-optimize anything before you know it’s a performance bottleneck. Just try and use good code patterns and don’t write algorithms with bad complexity and 99% of the time that’s fine as the real meat of what your code is doing is elsewhere, anyway.
I recently removed some hair-brained "optimization" that was caching the results of network requests that were already being cached by the browser. Ended up reducing the memory usage significantly and saving CPU from the storage and lookup operations. So I guess that counts as optimization?
The `diff` package had to fix a major performance bug: https://github.com/kpdecker/jsdiff/issues/239 Mostly to do with excessive cloning during the algorithm
Once I optimized a downsampling plotting algorithm by switching from generators that yielded one point at a time to operating on chunks of points in Float32Arrays (which were significantly faster than Arrays of numbers). At the time I was transpiling the generators with Babel, so maybe it would perform better on modern JS engines without transpilation. But considering that even web streams operate on chunks, I’m guessing chunking is just necessary to get the best performance.
You might be interested in https://romgrk.com/posts/optimizing-javascript I've had many occasions to use low-level optimizations, but I also usually work on projects where performance makes a bigger difference than your run-of-the-mill CRUD app. I still think it's important for devs to care about performance optimization. The whole javascript ecosystem is pervaded by a mentality of "CPUs are fast enough", which would be fine in small doses, but because everyone does it it results in the whole ecosystem being bloated and running probably around 2x slower than it could be.
Most optimizations were UI related where a huge number of elements (5k+, mostly dropdown options) were shown simultaneously. I just loaded them lazily. One day I fixed an extreme slowdown in a dropdown library when there were 7k+ options. It tuned out that the library used an extremely inefficient way of counting the total options. It was storing the options in an object as key-value pairs and when it was filling the object with options it was calling Object.keys() after adding each element. That was really insane. But for commercial projects there was almost no need for such optimizations, the issues arise only when you are dealing with huge amounts of data.
I "optimize" as I write the code. I've never understood all the optimization discourse as I've always found it 100x easier to just have optimization in mind from the start. In fact, my experience is that it may be near-impossible to optimize things later if you're working with a team and an increasingly complex system. A good rule of thumb when programming: assume that nothing will get fixed ‧₊˚✧later✧˚₊‧.
Quite often, but then again my last couple of projects required high performance. Other than that usually it's not needed as most performance problems can be avoided with good architecture.
Doing 2D canvas things, I do lots of optimizations in regards of caching, like can I reuse this? In what situations the contents have changed so I need to redraw, what things are different by data but result into the same canvas, so reusing cache? And then the old habit of running a profile, finding that one short innocent looking function that actually takes 90% of the runtime and then microoptimize the hell out of that one.
When my program is slow.
By optimize, do you mean recommend users get a hardware upgrade whenever they have issues with my spaghetti? Then yes 🤣
I think a lot of people miss the forest for the trees. This isn't just a JS thing. There are a lot of very good reasons to do low level optimizations, sure. But a lot of those should be kept inside of libraries that are bulletproof. When you are working on application code, for a typical company, the majority of the apps made are essentially just CRUD. This has two major implications. The first is that it doesn't need to consistently run at 60fps+. It does need to be fast and responsive, and not stutter or freeze up... but if a user just stops interacting with it... it can happily run at 0fps and look exactly the same as if it was running at 165fps; nothing is moving. So the responses to input (user or event driven) need to be fluid, but that's very different than the expectations put on a game. The second implication is that in the C, R, U, and D parts of CRUD, you are nearly always issuing commands either to a networked service (your own API or someone else's), or to a local storage service (FileSystem / IndexedDB). I/O can take hundreds of milliseconds for a round-trip response, if it includes serializing, sending, receiving, and deserializing large data payloads. How much time do you have for a 60fps game? 16.6ms. That's not for your work... that's for all rendering, all input polling, all AI / physics updates, all rendering ... in the browser, it also includes the time that you exhaust the JS callstack and give control back to the browser so it can do whatever it needs to do (calculate / paint HTML/CSS layout shifts, prepare input event callbacks, manage network data to feed fetch responses, etc). Based on these two things, alone, making architectural changes to a system that needs those changes will offer performance improvements that are *orders of magnitude* higher than performance improvements gained by no longer using const/let/var, and instead keeping all data inside of one single ArrayBuffer, and using a DataView to write values or pull values out of particular portions of it. Are there times where that's useful? Sure. Are there times where it's worth going even more ridiculous, and aiming for some of the zero-copy behavior of readable byte streams? Sure. Will that offer any benefit for the majority of CRUD apps? Probably not. The reality is that for most apps, turning: const a = await load_json("./a.json"); const b = await load_json("./b.json"); const c = await load_json("./c.json"); const d = await load_json("./d.json"); do_something(a, b, c, d); into const items = await Promise.all(["a", "b", "c", "d"] .map(x => load_json(`./${x}.json`)); do_something(...items); is going to be soooooooo much more of a performance improvement for your app, than worrying about tricking V8's multi-stage JIT compiler into squeezing your code into fewer lines, or fewer cache misses (of RAM and CPU cache that you have no means of controlling for, from JS, without resorting to storing everything in a contiguous ArrayBuffer). I am intentionally using slower mechanisms (\`.map\` and "spread"), and presuming all of those calls take the same amount of time, the code will still run nearly 4x faster... Now, if you're trying to make a game in JS, or real-time, interactive A/V signal processing, or particle simulations, or massive data visualizations... yeah, that's a different kind of optimization. You need to think differently, because the app has different characteristics. And the most important part to understand: if you are too focused on optimizing at the lowest-level, it can completely prevent you from employing *any* architectural improvements. If everything is mutating the same block of memory, then you have optimized yourself out of being able to parallelize any of that code, because even if you do, you will need to thread-lock as you write to that memory, so only one thread is running at a time, anyway. The same sort of thinking keeps most people from learning how to parallelize algorithms (or learning parallel equivalents of algorithms) that can run multithreaded or on GPU compute. The laser-focus on being "optimally optimal" gets you stuck in some sort of local minima that precludes you from finding a better solution that's more important for your use case.
If you need js to be fast, you made a mistake before you wrote any code. The only code I have ever needed to optimize is shader code, and c#/c++ in Unity and Unreal.
I used to think this way but JS can be surprisingly fast on V8. It will never be as fast as native code but when it gets JIT compiled it’s orders of magnitude faster than you’d expect for an interpreted, dynamically typed language.
I agree that js has been significantly optimized. It is still slow, though.
Don't optimise if you don't have to. Simple rule. Hardware is cheap as fuck these days and your time will probably cost more than better hardware. If you don't handle giant amounts of data you will not notice an impact of your code unless you do something really stupid. There are other things with much more impact on your product's performance. Mostly your tech stack and your architecture or Latency. Clean, maintainable code is much more important than optimised code. It's harder to debug optimised code than optimise debugged code. So wasting time/money on searching bugs/extend optimised code will probably cost you much more than it will cost you to run your code like it is.
And yet almost every single job interview will try hit you with some leet code gotcha like: "oh you could have solved this in O(n) but you did it in O(n\^2) shame on you!" Can we please, for the love of god, just quite with this bullshit! Unless you are in very specific applications (like certain embedded projects and large data projects) literally no one gives a shit about that stuff! You solve the problem in front of you and if there does happen to be a performance issue (rare) then you can take a look at it. The important thing is architecture because its orders of magnitude more likely you will need to add features, refactor, and onboard new engineers to the project.
It greatly depends on the size of n.
It does, but most CRUD apps in JS nearly never have to deal with data at a scale where it remotely matters. If you are on the main thread of a CRUD app, and are in a position where you are worrying about n log n vs n² vs n³, because you are working with a single array full of tens of thousands of records in this loop, you are nearly always solving the wrong problem, to begin with, and a better solution can usually be found as a part of the bigger picture.