That isn't reading the graph correctly. The saw tooth pattern means that memory is being allocated, but not that it's slow. The CPU usage graph tells you if it's slow.
Object pooling is generally considered to be the worse approach, because it's tricky to know when to put object back in the pool. Realistically this mean ref counting. The code will get more complicated and bugs will happen when an object is returned to the pool but is still used. Each object will get bigger, since now it has to have an extra word associated with it.
Also, this puts undue stress on the GC. Collections won't pick up pooled objects, even when they could have been. This causes memory pressure because the program may actually need
to allocate a large amount of memory, but none could be freed up.
I think the real answer here is to just do less work. Don't try to change a program to let it keep using lots of memory.
Instead, make it so it needs hardly any memory in the first place.
> I think the real answer here is to just do less work. Don't try to change a program to let it keep using lots of memory. Instead, make it so it needs hardly any memory in the first place.
I mean sure, if you can. Fundamentally games need to maintain a fairly large a mount of state you can't wave that away. For a lot of games that means rapidly changing state too for example bullet hells constantly instantiating and destroying each bullets can get crazy expensive.
Object pooling is pretty simple for games because the logic is already there. Whatever game logic was causing the game object to be destroyed moves it back into the pool instead.
>Object pooling is generally considered to be the worse approach, because it's tricky to know when to put object back in the pool. Realistically this mean ref counting.
It's trivial to know "when to put object back in the pool" when just using it to avoid object creation in specific hot paths...
If one adds "ref counting" then they're re-implementing their own full-ish GC on top of JS...
Probably want a (2013) in the title. JS GC is a lot better now than back then.
There's 2 main challenges to a pool based approach
1) Knowing up front how much memory you'll need
2) Complex DOM object pooling
In practice 1 gets solved by growing your pool, this also solves the problem with startup delays due to pre-allocation, but you need some way of knowing when to stop growing the pool and potentially evicting/re-using pool members. You can easily find yourself simply having written a much worse garbage collector of your own.
#2 is the realm of things like React-Virtualize. You need to be cognizant of acquiring handles to browser resources, and how to manage those life-cycles. You can end up in a case where your pool is 95% properly managed, but the leaky 5% still makes costly GC pauses.
Important to note: this effectively disables garbage collection, and therefore obviously can lead to a LARGE increase in memory usage.
In C++, there are kinds of programs where "#define free(x)" results in the same effect, including the large speedup.
But this is an important trick that also works in Java, C++ and Go.
It can be combined further. For instance, where you're keeping track of many small pieces of a big chunk of data, having the big chunk somewhere with a big primitive type array containing the actual data and then having Flywheel pattern accesses to it can result in incredible speeds.
Shit on the language all you want. Not only is it irrelevant, but also ill informed since a lot of performance critical things need to happen in the web environment. As such it is bound to happen in JS. No escaping it.
Except, perhaps, with our own hands. Web f.e. techs being fractured, redundant, incomplete, endlessly changed and bloated as they are is obviously extremely suboptimal. Better alternatives can easily exist. It's a disruption question. If the superior solution can survive through every obstacle it will face which tries to prevent people from hearing about its superiority and actually trying it, it will supplant the existing one.
Object pooling is generally considered to be the worse approach, because it's tricky to know when to put object back in the pool. Realistically this mean ref counting. The code will get more complicated and bugs will happen when an object is returned to the pool but is still used. Each object will get bigger, since now it has to have an extra word associated with it.
Also, this puts undue stress on the GC. Collections won't pick up pooled objects, even when they could have been. This causes memory pressure because the program may actually need to allocate a large amount of memory, but none could be freed up.
I think the real answer here is to just do less work. Don't try to change a program to let it keep using lots of memory. Instead, make it so it needs hardly any memory in the first place.