Strides Interactive

Differences between a design-based leak and memory hoggingFiled Under: Weekly Tuesday Dose of goodness

Dear all!

After serving the nation for 2 weeks, I’ve finally returned to civilization! This week, I’m going to share with you some of the terms I’ve picked out previously over the last few months.

Those who have read my previous posts would have known that I’ve written an article on Design-based leaks aka Legal leaks. Have you heard of the term - Memory Hogging?

So, what’s the difference between the two? How can we find them? How do we tackle memory hogging?

Let’s find out…

Introduction

First of all, I’ll like to introduce the key difference between design-based leaks and memory hogging. In most cases, they’re technically the same, much alike typical memory leaks.

However, there’s one major difference between them.

Design-based leaks occur due to lack of air-tightness in design, thus causing memory orphanage even when there’s a garbage collector or reference counting mechanism to clean up memory.

Memory hogging however, is due to poor memory design and memory economy or even worse, memory abuse. By design, these objects in memory tend to spam the scene with little or no value at all.

While both types of leakages are mainly caused by spamming of memory objects, the key difference is that, memory hogging is known, design-based leaks is not known till the application exhibits lag and excessive memory usage.

Detecting Memory Hogs

Fortunately and unfortunately, it’s usually easier to detect memory hogs than design-based leaks especially when the object is represented by a graphical object on screen. (such as particles, dirt, so on)

It’s unfortunate because some memory hogs are extremely difficult to find. Most of them stem of unoptimized usage of memory or classes with large heap objects that are instantiated unnecessarily.

It’ll be good if a project team can have class diagrams or diagrams that record the technical byte size of the object in terms of direct and indirect sizes.

Direct size refer to the “stack” size of the object which is can be retrieved easily using sizeof()

Indirect size refer to the heap allocations required by the object. This measurement usually yields a range (because if the pointer is an interface, then its size can vary greatly)

Preventing Memory Hogs

Now we roughly know how to detect memory hogs by book keeping the object and class sizes, we now have the visibility to predict and prevent memory hogs altogether.

The first step is to ask - is this piece of memory really required in the application at that point of time?

If yes, then you’ll need to measure the amount of memory you wish to allocate to this category of objects. For example, I allocate 10MB of system memory for particle objects. Let’s assume that each particle object is roughly around 2KB in size.Therefore I should have no more than 5000 particles in my application at any one time.

Next, you can specify a specification to limit the absolute total number of particles to be 5,000 in your design documentation. This will open up the visibility and provide the  rationale of why there’re just 5000 instead of 50,000 particles in the application.

Conclusion

As you can see, memory hogs are usually known to the programmer or designer. It’s up to them to control the amount of memory allocated for individual categories of objects and tune them accordingly to their business requirements and target audience.

Although memory is relatively cheap nowadays, there’re many people with 512MB machines or less still.

Unlike design-based leaks, memory hogs can come to a compromise if need be. That is,  for example reducing the amount of objects from other categories in order to accommodate the one in question.

Another way of compromise would be to allow the users to control this category via LOD options (Level of details). In this sense, you actually pass on the responsibility of causing the lag to your players instead.

For design-based leaks, the leaks are definitely due to a flawed designed and must be fixed. There’s no compromise at all for any responsible developers out there.

Therefore, we’ve come to the end of another weekly tuesdays. Hopefully this article can help clarify the differences between various types of memory leaks.

As a bonus, I’ll present them in layers for your persual. The top level type of leaks will be the easiest to find.

1) Memory Hogging - As described in this post.
2) Standard memory leaks. Ie, new without delete, malloc without free, new[] with delete, etc
3) COM memory leaks. Ie, QueryInterface() or AddRef() without Release(). This needs some technical agreement in order to control the reference count properly without crashing.
4) Design-based leaks. - See my article on legal leaks and design-based leaks
5) Allocator-Race leaks. - Allocation faster than deallocation, in real-time threaded environment, it’ll eventually lead to out of memory situations. This depends on which allocator is being used as well.

Have a great week ahead!!

Signing off,
Jeremy