Slow performance with debug builds in ADL in 33.1.1.935 and newer

[FliplineStudios]

Problem Description

We were previously using AIR 33.1.1.743 for all of our live apps, and are now testing 33.1.1.935 and 50.2.2.6 for updating our apps. When testing the apps on PC, we've noticed a big performance difference with ADL with debug builds starting in 33.1.1.935, which continues into the newest releases including 50.2.2.6. We're seeing this when testing with gpu renderMode, and tested with swf-version 37 which uses D3D 9 by default, and tested with both swf-version 44 and 50 with the maxD3D tag set to 9.

I've attached Scout screenshots showing the performance differences:

33.1.1.929 still has good performance with debug builds:

Performance issues start occurring with the .935 version of ADL, with the same build used from the 929 test: (this is the app idling, but when you're interacting with it there are plenty of spikes with framerate drops)

Release builds in .935 and newer do not have this performance slowdown:

Debug builds in ADL from 50.2.2.6 have the same performance issue:

Release builds in ADL from 50.2.2.6 are still okay:

(Not sure if there are same/similar performance issues with other renderModes or D3D 11, since our apps only run well with gpu and D3D 9)

Steps to Reproduce

• Create a debug build using gpu renderMode
• Test in ADL in 33.1.1.935 or newer

Known Workarounds

• Use ADL from 33.1.1.929 (and remain on swf-version 44 / 33.1 AIR SDK)

[FliplineStudios]

@ajwfrost With AIR 51, I'm noticing the same issue with slow performance with debug builds on PC run with ADL (with "Runtime overhead" accounting for 28+ ms per frame vs the previous 5ms). Especially since we'll need to increase our swf-version if we want to use any of the new API changes, I was wondering if you had any idea why this issue happened and if there's any workaround?

This performance drop started with 33.1.1.935, and the main thing I've seen in the release notes for that version is this change, where you mentioned there would be an increased CPU load for the fix: https://github.com/airsdk/Adobe-Runtime-Support/issues/85#issuecomment-1237240174

Is this large increase for Runtime overhead related to that CPU load increase? And are there any configuration flags we can set to restore the performance back to how it was in 33.1.1.929 for debug builds?

Any ideas would be appreciated! We mainly use debug builds as we're developing on PC, and we install release builds on devices later, so this just relates to playback on PC in our case. And for reference, we're not using advanced telemetry.

EDIT: If we do use advanced telemetry, the performance issue goes away -- though since we're using FlashDevelop with the original Flex compiler, we can't add that flag unless we use a separate tool like SWF Scout Enabler after the fact, so not ideal for attempting to debug. So in our case, the bug fix in .935 for "performance issues if running without advanced telemetry connection" actually made things worse if we're not using advanced telemetry :)

[ajwfrost]

Hi @FliplineStudios - we've just tried to reproduce this but can't see it with a basic app (simple animation based on the onEnterFrame event handler). Is there a sample SWF (+ app descriptor) that you could provide that demonstrates the issue?

The change earlier I think was just to improve the accuracy of the multimedia timer which meant that the delays between frames were set up better when the frame rate and screen refresh rate were close/conflicting. Having advanced telemetry set up was also changing that timer setting.

But a drop in the performance with 935 shouldn't normally be caused by this, I'm wondering whether there's some other asynchronous event that's being handled each time which is then the reason for what you see, which may then be app-specific (i.e. a test case may not be able to reproduce this until we know which event it may be that causes it!)

If you are able to share the app, please use the below link to send it in: https://transfer.harman.com/requests/r2ARmQTtBggmF6eIAilJ90

thanks

[FliplineStudios]

@ajwfrost Thanks, sample project sent!

I should mention that this is only occurring while also debugging with fdb -- if I just launch the application via adl without the debugger, there is no performance hit. If fdb is started first though, "Runtime Overhead" is 20-30ms. per frame when we use 33.1.1.935 or later (when using an earlier adl, it's 1-5ms per frame). If you have any questions or need any other information just let me know!

[ajwfrost]

Hi

I've just run up FDB, and then run your script to launch via ADL, and in the Scout log it all looks okay still for me. Not sure whether the GPU is going to be making a difference here....

But the other thing to check is whether this is just a labelling issue: your FLM file suggested you're still getting a framerate pretty much of what you'd asked for. Are you able to run a Task Manager with the details or performance tabs to see whether ADL is also maxing out the CPU?

thanks

[FliplineStudios]

@ajwfrost I could send the full app if that would help, beyond the splash screen is when we start dropping into 15-20fps with that "Runtime Overhead" using up basically all of our frame time.

I just checked in Task Manager, and ADL is using 8-13% of CPU while fdb is running. Both the version with smooth performance (33.1.1.929) and the newer versions with slow performance are showing the same CPU usage for me, so it doesn't seem to be related to that...

Are you seeing a similar "Runtime Overhead" of 20-30ms. when debugging? Not sure if it's something specific to my PC hardware why I'm getting such a hit to performance. It's especially strange that the older .929 performance is great with very little Runtime Overhead, and it's only starting with .935 that it became unusable for debugging.

[itlancer]

@ajwfrost Issue still exists with AIR 51.0.1.4. With some Windows devices AIR applications has low performance. Especially with 4K video playback.

Tested with Windows 10 64-bit, Intel i7-1165G7, 16 GB RAM, Intel Iris Xe Graphics, DirectX 12, 4K screen resolution. 64-bit AIR application with captive runtime (no ADL) with 4K MP4 H.264 video playback (Video or VideoTexture, the same result in both cases). I can send dxdiag output if needed. Adding <maxD3D>9</maxD3D> to application manifest "restore" performance to normal for such devices.

May be related to https://github.com/airsdk/Adobe-Runtime-Support/issues/2503