Skip navigation

Performance issuses when using trace

The other day I was working on a custom component that could be dragged and resized, and in my updateDisplayList method I was tracing a couple things so I could see what was going on. I noticed some very drastic slow downs and I was pretty sure that it was my trace statements causing to much I/O overhead. Anyway this got me wondering so I created some tests to see just how much the trace statement can affect performance of a Flex App, because I have seen and written many lines of code where not all of the trace statements are removed before release builds. This used to no be a problem because inside of Flash we could choose to omit traces from our published version of the swf, but when writing Flex correct me if I am wrong there is built in way to remove traces.

Below I have made some examples to show the performance hits that come along with those extra traces. All of the examples here have been built using Flex builder release build.  While a trace here and there may not be to bad if they sneak their way into a loop or a validation method, which gets called very often, they can seriously slow your app down.

Want proof? Read on

I put together a couple Flex apps to demo how trace can slow down your app.  I decided that I will create a function that simply loops for a specific amount of time, in this case 100 milliseconds, and increments a counter with each iteration.  In these examples there is a button that will start the loop and once the loop has completed the total number of iterations will be displayed.  Now because there is no good way to include these swfs in this lovely wordpress blog below are links to where you can see these in action.
Trace Tests

The results tell the tale

I ran these tests on my laptop which has a dual core 2.5 with 4 gigs of ram and here is what I saw.  When I ran the test with traces I saw on average 500 iterations with the debug version of flash player and 60,000 with the normal version.  Then I was surprised when I ran the test with out traces where I saw around 900,000 iterations.  All I can say is wow, I mean I knew I/O was expensive but this was a much bigger difference than I thought there would be.  Now you might be thinking why do the trace statements even effect the performance here, because after all there is nothing being output.  But infact the traces are still happening even though you can not see them, for instance if you have the debug version of the flash player you can view these traces in the flashlog.txt file.  This is why the debug versions numbers were so low because each trace causes disk I/O.  This is another reason not to trace to much because someone could be reading your traces.

What can you do?

Another way is to wrap your trace statments in a conditional.  See the example below.

Conditional Trace Test 

Yeah I know you would not use a checkbox to control your traces in a real application you would be much better off setting a constant.

    private const DEBUGGING:Boolean = true;
    .
    .
    .
    if (DEBUGGING) {
        trace("what ever");
    }

Ok so thats not to bad but it still requires a code change to go from debug mode to release mode.  

As another alternative you could write a script to preprocess your ActionScript that removes all the trace statements before they you compile.  Not sure about you but I would rather not have a script messing with my code.

The better way to use trace

Thanks to ActionScript 3 we can now do compile time conditionals. Basically we set a variable during compile time that we can reference which we can reference in the code.  Again you will wrap your trace statements in a conditional but this time it will look a little different:

    CONFIG::debugging {
        trace(counter);
    }

Now some of you may have not seen anything like this before.  What this code is doing is checking for a compile time variable called “debugging” and if it is set to false the trace will be skipped if debugging is true of course you will get your trace statement.  This is pretty cool because now you can switch from debug to release with out changing any code. To add a compile time variable you simply use the following syntax to to your command line mxmlc or to the compile options in Flex Builder.

    -define=CONFIG::debugging,false

This works in both Flex Builder and via command line mxmlc or what ever else you use e.g. ant.  The code above would of course set debugging to false effectively removing all trace statements.  Then when you need to debug simply rebuild the swf with

    -define=CONFIG::debugging,true

and magically your traces will come back.  For more information on conditional compilation see Adobes site http://livedocs.adobe.com/flex/3/html/help.html?content=compilers_21.html.  Of course I have some examples to show you.  Keep in mind that both of these swfs were compiled from the EXACT same code the only change was in the compile options that were used to build it.

Compile Time Test

Conclusion

Well as you could see from the above examples while the trace statement is probably one of the easiest ways to do some simple debugging it can cause some performance issues. Anyways just keep in mind what I have talked about and use tracing only when necessary and try to remember to remove them when you are done.  If you can not remove them try wrapping them in a compile time conditional.

Advertisements

5 Comments

  1. sweet tip, thanks.

  2. Are all your samples compiled as debug and not a release build?

    • No, I built all of the above tests via Flex builder release build NOT as debug. In fact I stated this in the second paragraph.

      “All of the examples here have been built using Flex builder release build.”

      This was my main motivation for writing this as I was surprised that the trace statements made it into release builds. I was always under the impression that release builds would exclude all trace statements or at least have an option to do so, but that is not the case.

  3. Compile time conditionals – excellent tip. Thanks for posting.

  4. Thanks dude a lot of good information 🙂


One Trackback/Pingback

  1. […] Yup, they sure do. If, like me, you were always working under the assumption that trace() statements don’t make it into release builds of your SWF, then you are mistaken – they certainly do, and they do cause a significant performance hit. I haven’t done tests, but you can see one in this blog post. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: