#begin

How to Balance Resources

The next section of the book is about how you should or can balance resources. I think this concept is far more important in languages without garbage collection like c or c++ but David and Thomas will also talk about how to do it in Java. Now, knowing how to balance resources in any Unity3D application is critical. If you don’t do it properly the performance of your game will suffer. So let’s see what they have to say about this.

They start the section of with a quote by Bill Cosby… ouch! Haha.

But they say that we as programmers have to manage different kinds of resources like memory, transactions, threads, files all kinds of things with limited availability. I think that everyone who has ever built a video game knows this by some hard learned experience!

David and Thomas say that most programmers don’t have a consistent plan for dealing with resources. And I think this is true. For example; you can write your C# code to play nicely with garbage collection (GC). You don’t have a lot of impact on GC but you can organize and write your code in such a way to optimize it for GC. Especially Generational GC like we have in C#.

The authors give us a nice little tip to resource balancing: “Finish what you start!” haha yes… It’s a simple idea. If you open a file stream, close it in the same function. If you create some collection, dispose of it at the end of the function. That kind of stuff…

Now in unmanaged languages like c and c++ the act of balancing resources is far more important than with managed languages because you can assume that at some point garbage will be removed.

In C# specifically we can use the ‘using’ statement to help with disposing allocated or opened resources. I use this all the time and I think the dispose pattern is very clean and useful. I also think that, if you implement the IDisposable interface and thus expose the Dispose function you create some cognitive leverage that tells users of that class it contains resources that need to be cleared. This is polite and it’s a recognized pattern in the context of C#.

David and Thomas also talk about nested allocations. Which basically means that you have 2 or more allocations and one ‘needs’ the other. If you want to close these resources, you should deallocate them in reverse order. This all makes sense because if you close them in any other order exceptions could occur because streams or files are no longer open. Wrongly deallocated resources can also lead to deadlocks by the way! So your game might suddenly freeze up if your main thread is waiting for some data.

Next they also specifically mention that any initialized object in an OO language, is in fact a resource. Objects can hold all kinds of data which you cannot even see by means of encapsulation. I talked about the dispose pattern earlier. This is a great way to handle the clearance of internal data.

Also, they talk about exceptions. Exceptions can create massive problems while balancing resources. If you do not handle exceptions properly your opened files and streams can remain open leading to all kinds of interesting problems. So if you open a file, close it in the finally clause of your try-catch-finally block. C# has nice support for this so you should use it! And again, use the using statement when-ever possible and it makes sense. Sometimes you cannot use the using statement because you need to keep some resource open for a prolonged time. But in other cases, you just need to open a steam and write some data to it. When it’s done you close it and move on.

So that’s about it for the interesting stuff in this chapter. How then does to relate to Unity3D. Well a lot! I’ve had the pleasure to trace down so god damn many memory leaks during my career so far it’s not even funny. A simple example: I would like you to remember that if you download some image file from the web and create it into a texture, and then create a sprite. You MUST call destroy on both the texture and the sprite when you want to dispose it. If you don’t you will have memory leaks. This will make your apps crash all of the sudden, out of thin air. When this happens, you can enjoy profiling and checking the memory profiler for leaks. And of course I’m joking. This is hardly fun. It sucks but it’s necessary. The same goes for audioclips by the way. And also for assetbundles. You need to unload then once you are finished with them. It’s really important for the memory footprint of your application.

So my advise concerning resource balancing is to use the dispose pattern and using statement when ever it makes sense. It’s a recognizable pattern in C# so when devs see that the interface is implemented they assume there are resources that need to be cleared once they are done using some class. Also, with any Unity3D resources, the ones that inherit from UnityEngine.Object, you need to call Destroy(object) to clear them from memory. If you don’t the spaghetti monster will at some point visit you.

So… and by that we end chapter four of The Pragmatic Programmer, and that’s it for today.

What do you think about the topics from this chapter? What do you think about the Design by Contract practice? I think it’s pretty neat but you will need to implement it yourself. It will give you some great handles on battling errors and bugs. Combined with the fail fast mentality this will surely lead towards more understandable apps.

I’m not so sure about the assertive programming style they described in this chapter. But that’s mainly because I’ve never really seen it used in C# and a Unity3D context. I believe it can be really helpful but I don’t expect people will ever use it. Maybe in other languages and platforms it is but not so much with Unity3D.

Then we also looked at when to use exceptions. They should indeed be used in exceptional cases. Don’t just start throwing exceptions for every piece of shit you encounter. Remember Prof. Ousterhout’s principle of defining errors out of existence. I know I have mentioned it far too many times in this blog but I really think this is a really cool, and fundamental principle for writing clean code.

And last we also talked about resource balancing. All of this seems a bit common sense but it’s really important when you want to write a performant Unity3D app. If you don’t keep an eye on resources, performance will in the end suffer… Trust me, I’ve been there too many times. Do you have any tips on balancing resources? Let me know by dropping a comment below 🙂

#end

01010010 01110101 01100010 01100101 01101110