4 ms·

> having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. What projects

> having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. What projects were you working on that required that? It sounds interesting

tomxor 5y ago
Mostly a variety of web based science education simulations. Usually boiling down to some kind of miniature specialist physics engine or procedural animation. Beyond that, it's more of a personal philosophy than a requirement (I could easily have done all those things more carelessly, but the result wouldn't be so nice, some people's laps would be hotter, and some people would end up with a slow or jerky simulation). I like things to be efficient, I enjoy finding a balance between "efficient" and "minimal". That doesn't mean I avoid GC all over the place adding unnecessary complexity and over optimizing, it just means being considerate where it matters and "idiomatic" where it doesn't - in a physics engine (or any kind of posteriori simulation) it matters because it's running on an interval and will constantly cause perceptible GC hiccups if you don't be considerate with memory.
- fancy_hammer 5y ago
  Would love to read a blog post about what this kind of code looks like!
Jasper_ 5y ago
I've done this before for plenty of tight loop code. Nothing irks me than staring a profile and seeing "Major GC" multiple times in the middle of a big algorithm. It's certainly not helped by the latest language fads just completely flooring the GC gas pedal; special mention should go to for...of creating a brand new object for each loop iteration. That's usually the first thing I rip out of tight loops. A bit of care can make this stuff go 3x fast on PC, and I've gotten completely unusable experiences on mobile (most websites) to be 30-40fps.
- triyambakam 5y ago
  Do you have any resources you like for diving deeper into profiling and learning the nature of the JS GC?

tomxor 5y ago

Mostly a variety of web based science education simulations. Usually boiling down to some kind of miniature specialist physics engine or procedural animation. Beyond that, it's more of a personal philosophy than a requirement (I could easily have done all those things more carelessly, but the result wouldn't be so nice, some people's laps would be hotter, and some people would end up with a slow or jerky simulation). I like things to be efficient, I enjoy finding a balance between "efficient" and "minimal". That doesn't mean I avoid GC all over the place adding unnecessary complexity and over optimizing, it just means being considerate where it matters and "idiomatic" where it doesn't - in a physics engine (or any kind of posteriori simulation) it matters because it's running on an interval and will constantly cause perceptible GC hiccups if you don't be considerate with memory.

fancy_hammer 5y ago
Would love to read a blog post about what this kind of code looks like!

Jasper_ 5y ago

I've done this before for plenty of tight loop code. Nothing irks me than staring a profile and seeing "Major GC" multiple times in the middle of a big algorithm. It's certainly not helped by the latest language fads just completely flooring the GC gas pedal; special mention should go to for...of creating a brand new object for each loop iteration. That's usually the first thing I rip out of tight loops. A bit of care can make this stuff go 3x fast on PC, and I've gotten completely unusable experiences on mobile (most websites) to be 30-40fps.

triyambakam 5y ago
Do you have any resources you like for diving deeper into profiling and learning the nature of the JS GC?