2 ms·

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 i

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.

coldtea 9y ago
>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...
nimos 9y ago
> 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.

coldtea 9y ago

>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...

nimos 9y ago

> 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.