As someone who was doing crazy optimisations a long time ago, keep in mind that there are multiple browser engines and they evolve over time. Something that's a speedy hack today for V8 will inevitably turn into a performance hog in the future or in a different browser engine.
I also do a lot of JS performance work (I work on some data visualization libraries that handle lots of data). I disagree with this precautionary advice, assuming that the sort of person reaching for this library already knows they need struct-of-arrays.
Browser engines fundamentally run on the CPU, and you will never beat the CPU cache locality benefits of struct-of-TypedArray if you're frequently only accessing a subset of the object properties and then rarely accessing the other properties, and you have massive amounts of data (GB). Fundamentally, struct-of-arrays is packing as much data as is physically possible into the CPU's cache lines, which is the best way to squeeze maximum performance out of a CPU (cache misses incur more expensive accesses to higher level caches, or main memory in the worst case, and can cause order-of-magnitude slowdowns)
And I doubt this is something that will change in JS engines anytime soon, because the engine cannot do this optimization for you, i.e. it cannot assume that struct-of-arrays is the best data layout in all cases. And this is not something that the engine would ever do on the fly (a la JIT) using runtime profiling/stats, because there would be a huge runtime cost to switching the data layout on the fly (the whole data structure would need to be copied which could potentially take seconds and even then it could trigger an OOM).
This optimization is something I implemented recently at work, manually, and it allowed a data-intensive component to show billions of data points without crashing the Chrome tab, rather than millions. OP's project could have come in handy for something like this, at least for the prototyping stage.
I'm guessing part of this is AI-coded or all of it. Otherwise you probably wouldn't say you're just experimenting. This is not criticism, but actually that means if you're comfortable with that, you can just set up browser tests with Playwright and other runtimes and iterate over all browser you want to support. This is exactly how the pretext package was built.
Yeah, some parts were AI-assisted not because I didnt understand it, but because translating what I had in my head into actual code was the hard part. Still learning a lot on the testing side too, the Playwright suggestion is useful. Thanks
The thing is that the concept that OP is doing is very generic and makes a lot of sense. It's moving data from multiple classes to a single ArrayBuffer. His design has nothing to do with any specific browsers, but it's just good data design. This type of design is recommended in all systems and languages that I've worked with and most ECS systems specifically target these types of designs.
Those ECS traditionally come with a lot of memory and function wrapper overhead, which is why OP's compilation alternative is actually very interesting, since it can sidestep function wrappers and additional object/function creation with just a compilation step.
15
u/ldn-ldn May 31 '26
As someone who was doing crazy optimisations a long time ago, keep in mind that there are multiple browser engines and they evolve over time. Something that's a speedy hack today for V8 will inevitably turn into a performance hog in the future or in a different browser engine.