Oct 09 2011
Profiling is fun
Actually, that’s a dirty lie.
Profiling is fun when it shows you something big that’s easy to fix. Profiling is a lot less fun when everything is equally slow. But luckily in my case, there was something big to fix. :)
I noticed the other day that editing roads in MMORPG Tycoon 2 had become extremely slow. (Well.. actually I noticed that roads didn’t draw at all. It was only after I fixed them not drawing that I noticed that they were slow to edit). This was odd, because I have videos of early road editing, where it hardly touched the frame rate at all on a system much slower than the one I’m using now. So after some profiling, I found that creating their procedural geometry was taking up about 75% of the whole processing time for the frame when they were created. This was extremely bad when editing them, especially (because they’re regenerated every frame, when they’re being edited, or when the ground under them is being edited).
Those of you who were at Freeplay will remember the part of my talk where I discussed optimising games, and when to do it (or rather, when not to do it).
For those who weren’t there, the tl;dr version is this: don’t optimise anything unless you have timing numbers that proves it’s slow relative to the rest of your program, and against which you’ll be able to judge your progress. Ideally, you get these numbers by using a profiler of some sort. (Visual Studio has one built in, modern Xcode uses Instruments while old Xcode used Shark, under Linux you have gperf, etc)
What I didn’t say in that talk (and which I’ve regretted ever since), is that there’s a second criteria which can make it acceptable to optimise some code, even if you don’t have performance numbers. Here is that other criteria:
Comments Off