Performance vs Error Checking

Hi everyone, Vlad here!

Seems like on a thing versus some other thing rampage with Application Design vs Game Design shortly followed by this post. I guess that’s a good thing, it means there are challenges and doubts and that we need to research.

This post is also inspired by some books I’ve been reading lately and that I highly recommend: The Productive Programmer that was influenced by The Pragmatic Programmer.

Problem #1

We are writing code and there’s not such thing as writing code without bugs. Sometimes our oldest, most used code, that code that we trust each of our games with gets into a specific spot where a hidden bug appears and we spend hours and hours figuring out what’s happening.

Solution #1 is Problem #2

There are several solutions to this. Writing code that includes testing is in my opinion the best. The problem with this, game development wise and specifically in scripted languages such as AS3, is that this makes the code much slower. The solution was checking for inconsistencies and not performing operations instead of throwing errors and exceptions.

I ended up creating conditions for use. For instance our blit package uses three different types: the core, the object and the texture. The core keeps the state of the whole system, the object keeps the state of what and where to render and the texture keeps the state of BitmapData. If the object did not have a texture it would simply not render. Sounds pretty cool, right?

To be honest… wrong…

Problem #2.1

First problem was the times where the position had NaN value instead of a Number. This rarely happened but every time it did it was a huge headache to identify why and then track the source of the bug down. While this seems unrelated, the fact was the it looked like the texture did not exist. So I had to check if the texture was created, if it was passed, if it was there at all and the worst part was that if the texture was there as it should, where the hell was the problem?

Problem #2.2

Performance wise checking if there is a texture is absolutely dumb! 99% of the times there is a texture present. More, the object class has a visible variable. If the object does not have a texture why is it visible in the first place?

So while apparently I solved a problem by checking if the texture was present and not performing any blit operation if it wasn’t, the truth is that both performance wise (not that serious by the way, it’s just a if statement) and the unwanted problems it induced in the code backfired from time to time.

I spread this type of behavior through the code. While one if statement does not have a large impact in performance, a lot of checking piles up and I had a lot!

Solution #2

A short story and a riddle both taken from those books that explain my thoughts on the ‘final’ (we’ll see about that!) solution for these problems.

The first one was when one of the authors was hired as a consultant for a development project where the coders sent broken code to the version control system. What he did was to create a routine where the version control server would compile the code that was pushed. Every time the compilation didn’t work the server would send an email with the error. With the amount of mail with errors constantly piling up on mailboxes, one of the coders asked if there was a way of not getting that much email. The consultant replied: “Sure, don’t push code with errors!”

The riddle is… what code takes not time to be executed? The one that is not compiled.

So the solution is to write code that allows zero error tolerance while not compiling it. The way to achieve this is with conditional compilation which can be used in several way but these are the ones I believe the most useful is to use code blocks, like this:

1
2
3
4
5
6
7
8
9
10
11
private function someFunction():void {
    CONFIG::debug {
        // Development code
    }
    CONFIG::release {
        // Final code
    }
    // Both dev and final code
}

Inside the same function, different code is compiled depending on the current configuration. We can have several checks with exceptions and errors being thrown and then have a ‘don’t check at all’ version in the release configuration.

This is a two stage solution really. On one hand every time I do something stupid, I get errors so my code has to be perfectly implemented at least when it comes to our framework. On the other hand the same code that make me code as best as I can is also the code that does not run in the final version.

 

Posted: February 5th, 2012
at 12:55am by Vlad

Tagged with , , , , ,


Categories: Dev Journal: Danger Zone,The code of VGS

Comments: 4 comments