Marc Hughes


Home
Blog
Twitter
LinkedIn
GitHub
about
I am a developer from a bit west of Boston.

Profiling experience

13 Jul 2009

Today, I happened to have Activity Monitor open while I was working on AgileAgenda and noticed something peculiar.  It was sucking up 200% of CPU time (multiple cores...)

So I fired up the application in the Flex profiler.  Let it sit for a minute, clicked the "Reset Performance Data" button, waited another few seconds, and then clicked the "Capture Performance Data" button.  The result was odd.

Nothing was actually in code I could touch and didn't explain why it was happening.  There had to be something going on to peg out the CPU like that.  So I hit up the Flex preferences panel and found something I had forgotten about.

By default, the profiler excludes a whole bunch of flex and flash related classes from the profiler.  So I removed those exclusions and unchecked the box.  Went back to my profile window and low and behold, this is what I saw:

So now I had an idea of what was happening.  It looks like that indeterminate progress bar (which wasn't on the screen anymore by that point) was sucking up some render time.

So I peeked at the ProgressBar flex code.  They've got a timer in there that gets started, and is stopped when the progress bar is set to invisible.  But that doesn't end up accounting for cases where we just bump to a different parent object in a view stack.  So that timer sits there, happily spinning and consuming resources.

I added some code in to manually set the visiblity of the 2 indeterminate progress bars I had and ran.  Bamn, success.

So I learned (or re-learned?) two things today.

  1. When profiling, if you don't see anything happening check your filters.
  2. Be very careful with indeterminate progress bars in flex.
Note: I got similar results both in the debugger (ADL) and when running the application stand-alone as a bundled application.