Hope they don't adversely affect Node's performance with this tuning for low memory devices
There is no downside to keeping the overall memory arena size down: better cache locality, fewer stop the world collections. Node programmers have been asking for this behavior for years.
Fall cleaning: Optimizing V8 memory consumption
21–30 of 43 posts
Re: Fall cleaning: Optimizing V8 memory consumption
#22Piggybacking on this, can anyone recommend an approach for finding the cause of memory issues in v8? In my case I'm tuning a 3D game, and the heap usage is a sawtooth pattern with GCs about once per second. Not awful, but it would be nice to smooth it out. But playing with Chrome's various memory profiling tools I've never been able to discover where the allocations are coming from - the results always seem to be dom…
Re: Fall cleaning: Optimizing V8 memory consumption
#23Piggybacking on this, can anyone recommend an approach for finding the cause of memory issues in v8? In my case I'm tuning a 3D game, and the heap usage is a sawtooth pattern with GCs about once per second. Not awful, but it would be nice to smooth it out. But playing with Chrome's various memory profiling tools I've never been able to discover where the allocations are coming from - the results always seem to be dom…
Is the game open to public? I would like to give it a look, i have done some amount of optimizations as a hobby.
Re: Fall cleaning: Optimizing V8 memory consumption
#24Piggybacking on this, can anyone recommend an approach for finding the cause of memory issues in v8? In my case I'm tuning a 3D game, and the heap usage is a sawtooth pattern with GCs about once per second. Not awful, but it would be nice to smooth it out. But playing with Chrome's various memory profiling tools I've never been able to discover where the allocations are coming from - the results always seem to be dom…
Is the game open to public? I would like to give it a look, i have done some amount of optimizations as a hobby.
Actually now that I take a second look, some relatively simple demos of the same engine (Babylon.js) show the same sort of behavior. Some rather trivial three.js demos do as well. I might be dealing with something that's just a fact of life for webGL rendering.
Random example (not mine) showing a vaguely similar sawtooth of heap memory usage:
Re: Fall cleaning: Optimizing V8 memory consumption
#25Piggybacking on this, can anyone recommend an approach for finding the cause of memory issues in v8? In my case I'm tuning a 3D game, and the heap usage is a sawtooth pattern with GCs about once per second. Not awful, but it would be nice to smooth it out. But playing with Chrome's various memory profiling tools I've never been able to discover where the allocations are coming from - the results always seem to be dom…
I'd love to take a look deeper - contact info is in my profile if you're interested.
Re: Fall cleaning: Optimizing V8 memory consumption
#26Piggybacking on this, can anyone recommend an approach for finding the cause of memory issues in v8? In my case I'm tuning a 3D game, and the heap usage is a sawtooth pattern with GCs about once per second. Not awful, but it would be nice to smooth it out. But playing with Chrome's various memory profiling tools I've never been able to discover where the allocations are coming from - the results always seem to be dom…
Usually that's because you're creating and disposing of a lot of objects in your game loop. Look into initializing a lot of objects at the start and reusing 'em (usually called object pooling). I'd love to take a look deeper - contact info is in my profile if you're interested.
One suspects that DevTools' memory profiling should be the place to start, but I haven't found any way to get it to shed any light on where allocations are occurring. So that's what I'm asking about here.
Re: Fall cleaning: Optimizing V8 memory consumption
#27Hope they don't adversely affect Node's performance with this tuning for low memory devices
Re: Fall cleaning: Optimizing V8 memory consumption
#28Piggybacking on this, can anyone recommend an approach for finding the cause of memory issues in v8? In my case I'm tuning a 3D game, and the heap usage is a sawtooth pattern with GCs about once per second. Not awful, but it would be nice to smooth it out. But playing with Chrome's various memory profiling tools I've never been able to discover where the allocations are coming from - the results always seem to be dom…
Re: Fall cleaning: Optimizing V8 memory consumption
#29Earlier quoted context omitted.
Usually that's because you're creating and disposing of a lot of objects in your game loop. Look into initializing a lot of objects at the start and reusing 'em (usually called object pooling). I'd love to take a look deeper - contact info is in my profile if you're interested.
Sorry if I wasn't clear, but the problem is finding the allocations, not fixing them. (They are probably happening in the 3D engine, i.e. code I didn't write.) One suspects that DevTools' memory profiling should be the place to start, but I haven't found any way to get it to shed any light on where allocations are occurring. So that's what I'm asking about here.
Re: Fall cleaning: Optimizing V8 memory consumption
#30Piggybacking on this, can anyone recommend an approach for finding the cause of memory issues in v8? In my case I'm tuning a 3D game, and the heap usage is a sawtooth pattern with GCs about once per second. Not awful, but it would be nice to smooth it out. But playing with Chrome's various memory profiling tools I've never been able to discover where the allocations are coming from - the results always seem to be dom…
* https://gist.github.com/krisselden/d3ce3cbb37cc6035b0927fdbf...
It flips some handy flags providing useful output, this output can quickly illuminate issues the regular tools do not (yet).
Running this on the example you linked to bellow, shows that a series of functions are deopting and optimizing repeatedly. most likely causing at-least some of the sawtooth pattern you see.
example output (likely related to the problem):
```
removing optimized code for: r.getViewMatrix]
[removing optimized code for: r._isSynchronizedViewMatrix]
[removing optimized code for: r._computeViewMatrix]
[removing optimized code for: r._isSynchronized]
[removing optimized code for: r._computeViewMatrix]
[removing optimized code for: r._isSynchronizedViewMatrix]
[removing optimized code for: r._isSynchronized]
[removing optimized code for: r._computeViewMatrix]
[removing optimized code for: r._isSynchronizedViewMatrix]
[removing optimized code for: r._isSynchronized]
[removing optimized code for: r.getViewMatrix]
[removing optimized code for: r._isSynchronizedViewMatrix]
[removing optimized code for: r._computeViewMatrix]
[removing optimized code for: r._isSynchronized]
[removing optimized code for: r._computeViewMatrix]
[removing optimized code for: r._isSynchronizedViewMatrix]
[removing optimized code for: r._isSynchronized]
[removing optimized code for: r._computeViewMatrix]
[removing optimized code for: r._isSynchronizedViewMatrix]
[removing optimized code for: r._isSynchronized]
[removing optimized code for: r.getViewMatrix]
```
---note: Credit for this should go to @krisselden the author of the above gist not me.