Image.Discard() not working - iOS
Monkey Forums/Monkey Bug Reports/Image.Discard() not working - iOS
| ||
| Image.Discard() is not working on images with multiple frames. Nobody seems to have moved it, so I have re-posted in the bugs forum as per request from this thread |
| ||
| Will fix. Note: The image will eventually get discarded, only when GC gets around to it as opposed to when you call Discard. But that's not ideal... |
| ||
| I'm guessing this wasn't fixed yet as the thread hasn't been moved out from the bugs forum? I'm using v76d, OSX 10.8, XCode 4.6.3 I was just testing my app which loads in images for a world, then deletes them (using discard images) and then loads in a new set of images. I'm not using images with multiple frames. Also objects are created and destroyed for each world too. Anyway, when I monitor the app with instruments (memory activity monitor) what seems to happen on my iPhone 4S is the memory use keeps going up every time I load a new world. The game starts at just 50Mb memory usage but repeated loading of worlds (with approx 5 seconds between loads due to manual testing) pushes it to over 300Mb (I've checked that discard is being called on the images by making sure the code gets there). However, sometimes the memory drops down a bit and if I leave the app and do nothing it slowly drops right back down to about 80Mb. So is this just how iOS/GC works? The app is allowed to keep allocating memory and the old memory (or just images?) isn't cleaned up until iOS decides to do it? I thought the GC ran every OnUpdate() (so 60 times a second in my game), and that should result in a much flatter memory use right? In fact, if I rapidly keep loading worlds the game eventually bombs right out as I guess iOS takes it down because the GC doesn't get a chance to work. So yeah I suppose images should really discard a bit quicker or at least discard when the app receives a memory warning from iOS. |
| ||
| > I'm guessing this wasn't fixed yet as the thread hasn't been moved out from the bugs forum? This issue was fixed in v76b. Is your app actually running out of memory? GC is incremental now - you can tune the collection rate with: CPP_GC_TRIGGER=blah, where blah is how many bytes to allocate before a GC occurs. This defaults to 8 Meg, but you can set it to 1 to cause a full gc every update/render. However, the lower this value, the slower the GC. |
| ||
| >This issue was fixed in v76b. Is your app actually running out of memory? Yes, further testing reveals that iOS will take down the app when it runs out of memory if I rapidly load worlds (as per notes above). I checked the version notes for v76b and I see you are discarding multi-frame images immediately (so I assume you are doing the same for single frame images). Perhaps it's not the images using up the memory but objects for each world? All are deleted when new worlds are created though, and I can see this is true because if I leave the app alone the memory drops back down to normal levels eventually. (I even noticed this happens if I run the GLFW version on my Macbook Air and monitor using instruments, so this isn't just an iOS issue, although it's a worse problem on iOS due to it killing the app) I'll try changing the collection rate to see if it makes a difference but I'm finding it weird how rapidly filling the memory up (way more than 8Mb) doesn't seem to GC. Or if Monkey is GCing that iOS doesn't recognise it. |
| ||
| OK I can confirm that adding #CPP_GC_TRIGGER=1 stops the memory going out of control on both iOS and my Mac (it stays at around 80Mb), although I believe that performance is decreased on iOS (just doing some more testing to find out). Maybe there will be some happy medium between 1 and 8Mb (default) Q. Is #CPP_GC_TRIGGER= in bytes? So when you say 8Mb is he default you mean 8388608 right? If so, maybe I could try out 1048576 (1Mb) or something? How come the default doesn't actually appear to work then? In theory the game should only go up to 88Mb then keep dropping down to 80Mb and not going sky high. Something weird going on. |
| ||
| > I'm using v76d, OSX 10.8, XCode 4.6.3 Can you try a more recent version of Monkey? v77a includes a tweak that may cause GC to happen sooner when large chunks of 'non-object' memory are allocated, eg: native image data. |
| ||
| OK will do and will report back. Thx. |
| ||
| Good news Mark! That totally fixed it. I'm using v77f and now it's very hard for me to make the app go over 100MB use even in unrealistic scenarios of use. The app seems to sit around 80Mb now no matter how many worlds I load and unload. So yeah looks like the non-object memory (images) wasn't being freed quickly enough before but it now is. Good work and thanks! |
   |