Skip navigation

Monthly Archives: April 2009

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.

I thought that I would write a little tutorial showing how to create a Flex application using the Adobe Flex SDK. The Adobe Flex SDK is a great tool because of how powerful it is an also because it is 100% free. I will cover where to get the Flex SDK, how to write mxml, and finally how to compile the application.

First Things First – Getting the Flex SDK

Before you can build any Flex applications you will need the Flex compiler (aka mxmlc). Not to worry you can get this for free as part of the Flex SDK. You can find the SDK on Adobe’s site or use the link below. Flex 3.3 SDK will work on all platforms.

http://download.macromedia.com/pub/flex/sdk/flex_sdk_3.zip

Once the download is complete you will need to extract the files from the zip. You can extract it anywhere you want, for the rest of this tutorial I will be assuming you extracted it into C:\flex_sdk_3. The main file you will be needing from here is mxmlc.exe which will be inside the “bin” directory (e.g. C:\flex_sdk_3\bin\mxmlc.exe).

 

Showing files extracted files for the flex sdk

Showing files extracted files for the flex sdk

 

 

We will come back to this compiler after we have some code to use it on.

Lets Write Some Code

We will be created just one file for this tutorial, so where every you would like create a new file named helloworld.mxml. I suggest making a folder for each of your Flex applications just to help keep things clean. For this example I created a folder called “hello world”. This file will simply be a text file so you can use what ever editory you like be it notepad, wordpad, emacs, jedit, ect, I will be using vim because its the best. The language used to write Flex applications is called MXML and like the name implies it is a form of XML so each MXML file needs to start with the following line at the very top.

<?xml version="1.0" encoding="utf-8"?>

Now lets add some actual MXML code, we will start with the <mx:Application> tag. This is the first tag that all of your Flex applications will start with. This is similar to how all HTML pages start with an <HTML> tag. Below is code for the most basic Flex app you coild possibly write.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
</mx:Application>

Here is a screen shot of me editing my mxml file.

 

Screen shot of editing helloworld.mxml using vim

Screen shot of editing helloworld.mxml using vim

 

 

Believe it or not this is enough code to compile so lets do that before we go any further to make sure that everything is working

Compiling Your Flex with mxmlc.exe

So we wrote a little code and now we want to see what it will produce. We will be using mxmlc to compile this mxml into a swf. So it is time for you to remember where you extracted your Flex SDK, I put mine in C:\flex_sdk_3 so I will be referencing that location, if you have it somewhere else be sure to make the appropriate changes to my instructions. Once you locate your SDK folder you will want to look inside for a folder called “bin”. It is inside of this bin folder that you will find the mxmlc compiler. There are two ways that you can use this compiler, the first and most simple way is to simply drag your mxml file and drop it right on top of mxmlc.exe. You will see a window open while mxmlc is running, which will close as soon as mxmlc is done. Assuming all goes well you will find a freshly made swf called helloworld.swf inside the same folder as your helloworld.mxml. While this way may seem super simple it has several draw backs. If there are compile errors you will not be able to see them because the window closes immediately. Secondly you will not be able to add any extra compile options using the drag and drop method. I suggest using the second method of running mxml from the command line. If you are in windows XP you will need to click on the start menu then click “run” and then type “cmd” and press enter. This will open up a new window with a command line. In Vista you simply click start menu and type “cmd” in the search box. Once you have the prompy open you will have to move to the directory where your helloworld.mxml file is located. Now to compile your Flex you simply run mxmlc and pass it helloworld.mxml as a parameter. To do that run the following command on the command line.

C:\flex_sdk_3\bin\mxmlc.exe helloworld.mxml

Here is a screen shot of mxmlc running on my computer.

 

Screen shot of running mxmlc from the command line

Screen shot of running mxmlc from the command line

 

 

Again once mxmlc is done running you will have a helloworld.swf in the same folder as you helloworld.mxml or you will see some sort of error message from mxmlc. Like I said before if you run the swf you will see nothing more than a blue background.

 

Screen shot of helloworld.swf

Screen shot of helloworld.swf

 

 

Lets add some more code

So we made an app if you can call it that so now lets do something a little more interesting. We will be using the <mx:Label> tag to display some text in our app. The <mx:Label> tag has a text attribute that allows you to set the text that you wish to display. See the code below:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Label text="This is my first app"/>
</mx:Application>

Now you should compile this again just how we did before. After you have compiled your mxml again if you run this swf it should like something like this.

 

running helloworld.swf with a Label

running helloworld.swf with a Label

 

 

Now lets add one more thing to this app before we call it a day, a Panel component. To do this we will use the <mx:Panel> tag. A Panel is similar to a window, it has a border and a place for a title. Lets take a look at some code.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Panel title="Hello World">
        <mx:Label text="This is my first app"/>
    </mx:Panel>
</mx:Application>

Again you should compile this code and see what we have now. Here is a screen shot of what it should look like.

 

Here is what the final swf looks like

Here is what the final swf looks like

 

 

Thats it

Well thats it for now I know this was a very simple example but I just wanted to get you used to using the compiler and writing some mxml. I hope I sparked your interest in Flex and you will continue to experiment and learn. Here is a link to the Flex 3.3 documentation:

http://livedocs.adobe.com/flex/3/langref/