GC overhead... where?
Monkey Forums/Monkey Programming/GC overhead... where?
| ||
| OK, I've been experimenting with pre-allocating objects versus New-ing them on-the-fly, based on the idea that "creating new objects is bad", in the hope of understanding and improving performance on more limited platforms. First of all, I do understand that it apparently makes a difference in some situations, or on particular platforms (eg. XNA on 360, which I haven't tried but understand to be particularly sensitive), so I'm not putting down the 'received wisdom'. However, this example seems to run pretty much the same whether I use a fixed, pre-allocated array of objects or just generate them on the fly in a list, and that's on my fairly modest Android phone (Orange San Francisco/ZTE Blade, 600 MHz ARM CPU), as well as HTML5, GLFW, etc. Examples in zip: explode.monkey - fixed array version explode2.monkey - careless list version It may be that it's a bad example, but I've made the array version stick to a fixed 500 object array (with 5 elements filled in per MouseDown'd frame, if slots are available), and left the list version to its own devices in terms of maximum allocation (still generating 5 objects per frame). (I'm not saying it necessarily runs totally smoothly, BTW, just that it seems no worse in either case.) I know others have seen great improvements in avoiding creating new objects, so I'm really just interested in why I'm not seeing any difference! Is the 'avoid New' thing somewhat overstated, or is this example just too simple? Is there something else I might be missing? |
| ||
| Just to clarify, this isn't meant to be troll-y or antagonistic! I was just expecting a noticeable difference when I tried this and didn't see any. |
| ||
| 5 objects per frame is nothing on any platform and is not a reason to pre allocate. it' when you create say 50 particles in a frame which themselves create another 50 vectors and/or additional objects per frame, that's how you should be testing. |
| ||
| i just get module autofit not found |
| ||
| Sorry, Dave, stick this in the same folder as the source files: http://www.hi-toro.com/monkey/autofit.monkey (If that fails, create a folder called autofit in Monkey/modules and place it there.) |
| ||
| hi,well i tested it on html and android and explode2 always has a worse framerate.i Changed the setupdaterate to 600 to get these results but on android there could be as much as 15 fps difference between explode and explode2.On html it was around 10 fps.You only notice it though when you got loads on the screen.I tested it on a galaxy tab 7". |
| ||
| I think it is really good that you don't take it for granted, but actually test the difference! Some pointers: * Test Allocation * Test Deallocation * Test for Jitter (unwanted changes in FPS) Usually jitter is the problem. And Jitter is what tends to happen with garbage collectors - They are usually not that wise, so they do "chunks" of deallocation that halts the program. And they tend to deallocate more often when you have less memory availible. Good for boring Apps. Often not so good for realtime Apps. However there is a balance here when those chunks gets so big that one starts to notice lag - and I have no idea what that size is when it starts to become noticable - but it would be cool to know! |
   |