1

I have an AIR Native Extension with a C implementation for Windows to provide access to the Kinect for Windows SDK. I am aware of AIRKinect, but certain factors require a custom solution.

Recently, a problem has been occuring, resulting in the whole application to slow down by the factor of ~100, when started from within Flash Builder 4.6 using the Run/Debug buttons.

Attempted Solutions

Initially, a reboot would allow me to run/debug the application once before the problem occurs again. Soon after, even this method started failing to work.

The problem seemed permanently solved when restoring the system to a state from one month ago. The only changes to the system that happened in this time frame are Windows updates. Installing new Windows updates today apparently brought the issue back to life.

It is confirmed that the cause of the problem does not lie in my source code - I rolled back to several past revisions, but the problem persisted.

Strangely enough, no problems occur when exporting the application as a release build, installing it, and running it like that. This workflow, however, is not suitable for day-to-day development, as the build takes a full minute, and proper debugging is not possible (at least I know of no way to attach the debugger to a running, installed AIR application.)

Location

By profiling the code, I managed to track down the unusually long run times to the calls to context.call. Curiously, the functions implementing the native part are fast as usual, when measuring the time passed between start and end of the function block.

This can only mean that the problem lies somewhere in between. Due to the lack of information on the Internet on cases like this, and I have exhausted the knowledge of myself and my colleagues. I greatly appreciate any advice that might help finding cause and solution of this problem.

user1548064
  • 11
  • 1

1 Answers1

0

It's not all that strange to have slower performance while running a debugger. this is typical for most if not all development, including the ADL.

While this won't shorten the compile time, you could create a simple debug class that would output trace statements to text field.

Chunky Chunk
  • 16,553
  • 15
  • 84
  • 162
  • The application was running perfectly fast in debug mode just two weeks ago, so I doubt that using the ADL _caused_ the loss in performance. I appreciate your effort, though. – user1548064 Jul 30 '12 at 06:12
  • are you only testing the native extension? even when i run Starling projects ADL can have a difficult time processing at 60FPS, while a release build couldn't be smoother. any heavy display objects (vector graphics, flash filters, masks?) added to your project in the past few weeks that may be slowing down ADL? – Chunky Chunk Jul 30 '12 at 21:21
  • The drop in performance happened literally without any changes to the code over a reboot. As I stated in the original question, rolling back to a revision that was confirmed to work properly did not solve the issue. So I think it's safe to say that it's not the fault of the application or the ANE. – user1548064 Jul 31 '12 at 06:37