It's probably obvious in hindsight, but treating pixels as std::vector<Color> means that every time you read a pixel, you allocate a Color object. In wasm or native compilation this isn't an issue as the compiler does a good job. But if you pass a vector of colors to JavaScript, it gets terrible: each pixel gets a heap allocation that needs to be freed, either explicitly or via a finalizer.
We could change pixels to be "value objects", meaning that when JS sees them, it sees only {r:10,b:20,g:30} or the like, with no prototype and no methods. That would allocate them via the JS GC, which does well at short-lived allocations like this. Or we could just change to be uint32_t RGBA pixels, which is probably best.
It's probably obvious in hindsight, but treating pixels as
std::vector<Color>means that every time you read a pixel, you allocate a Color object. In wasm or native compilation this isn't an issue as the compiler does a good job. But if you pass a vector of colors to JavaScript, it gets terrible: each pixel gets a heap allocation that needs to be freed, either explicitly or via a finalizer.We could change pixels to be "value objects", meaning that when JS sees them, it sees only
{r:10,b:20,g:30}or the like, with no prototype and no methods. That would allocate them via the JS GC, which does well at short-lived allocations like this. Or we could just change to beuint32_tRGBA pixels, which is probably best.Anyway, an interesting lesson learned here!