Unity’s garbage collector is super slow and the bane of our programming life. It’s the reason we can’t use foreach, have to make pools of objects, and go to great lengths to avoid boxing. It’s also seemingly mandatory, but that’s not quite true. Today’s article shows you a way that you can skip the GC and still allocate memory!
Posts Tagged memory
One typical piece of advice for dealing with the slowness of Unity’s garbage collector is to periodically force a garbage collection, such as every 30 frames. Even Unity advises this. The idea is that you’ll spread out the garbage collection work across many frames rather than having a big spike that causes your frame rate to stutter. But the question remains- what’s the best rate to force the GC? Today’s article tries out various intervals to see which is best. Read on for the results!
Unity’s garbage collector is old and slow. As garbage from your scripts piles up, the garbage collector will eventually run. When it does, it runs all at once instead of spreading the work out over multiple frames. This means you get a big spike on one frame causing your game to momentarily freeze. One of the best ways to get around this is to use an “object pool” to reduce the number of objects eligible for garbage collection. After all, if there’s no garbage then there’s nothing to collect! For more on this strategy as well as a class you can use to implement it, read on!
A Boolean in AS3 takes up four bytes of memory to store a single bit of information. It takes up 32x more memory than it needs. We can make better use of this memory and today’s article explains how.
flash.sampler.getSize() is a handy tool for figuring out how much memory a class instance uses. However, it is often flat-out wrong. Today’s article tries it out on a variety of classes to find out which ones it works on and which ones it doesn’t.
When you instantiate one of your classes, how much memory does it use? Today’s article tries out a lot of combinations and counts the bytes used. The conclusion is easy to remember and will give you a solid understanding of how much memory your app is using.
Last week’s article showed a variety of tricks for saving memory with ByteArray. Today’s article explores some tricks to use with BitmapData to save even more memory.
The ByteArray class is not as straightforward as you might think. In certain situations, it has surprising, undocumented functionality. Today’s article goes into some of these strange behaviors so you’ll get a better handle on exactly what’s going on behind the scenes.
When I first wrote about master strings I proposed a function that would help to trim them down and potentially save a lot of memory. However, that method still resulted in a string with a master string one longer than it. Ideally, we’d have no master string at all. Since then, three astute readers chimed in with alternate solutions to the problem. Today I put try all three out to see which method does the best job of cleaning master strings.
Dealing with XML files can very easily trigger Flash to “leak” memory. Your app may only keep a tiny fraction of the XML file’s contents, but the whole file may stay in memory and never get garbage collected. Today’s article examines how this happens and how you can clean up all that unused memory.