Performance Issues in Flash 30.

[Guest]

We are getting reports from users throughout the Scratch (scratch.mit.edu) community of performance issues related to Flash 30. Upon a deeper investigation it seems as if the main event loop is running much more slowly even in simple tests, this may have something to do with hardware (GPU) acceleration, but more investigation is needed. Results of a single benchmark for Chrome on MacOS are included below, but we are seeing the impacts of these across all 200+ million projects shared in the Scratch online community. We have also been able to repro this on Firefox and Safari on MacOS. We will be testing on Windows shortly and will post results here once complete.

Flash Version - 29.0.0.171

Google Chrome (PPAPI)

Macintosh (OSX)

Flash Version - 30.0.0.113

Google Chrome (PPAPI)

Macintosh (OSX)

[chris.campbell]

Thank you for the heads up.  Our team has reproduced the issue and we're now investigating further.

Chris

[chris.campbell]

We've made a necessary mitigation for Spectre/Meltdown-style attacks that significantly increases the cost of calls to getTimer() and related APIs (~100us).  This change isn't apparent in most content, but if you're calling getTimer in a tight loop, the impact is pretty pronounced. The best solution is to modify the content to use getTimer() more judiciously.

From our initial investigation into the Scratch codebase, it does appear that getTimer() is being aggressively used.  Can these API calls be reduced?

An alternative would be to set TimerJitterMicroseconds=0 in the system's mms.cfg file, however this is not recommended as it removes the benefit of the additional security mitigation.

[justtryme]

getTimer() now works about thousand times slowlier than in earlier vers. of FP. Don't you think it's a bad practice, to reduce performance with exploit fixes.

We would appreciate Adobe to release a fix for getTimer() calls

[jeromiec83223024]

Unfortunately, reality is messy.  We didn't create this particular problem, but as responsible actors in the web ecosystem, ignoring it also isn't an option.  The security of end-users is more important than backwards compatibility, and one of the very few instances where we would choose a drastic change to existing functionality.

This was also the most surgical option available, and effectively, the least terrible of multiple terrible options.  You'll need to modify your code to call getTimer() less frequently.  If you're highly dependent on high-resolution timing, that's unfortunately pretty problematic, but any browser-based solution for high-resolution timing in a post-Spectre world is going to be impacted to some degree.  Research into similar timing attacks against existing CPUs is an active area of investigation by the larger security community, and it's going to be interesting to see what that research bears over the coming months and years.

[SergStone]

You mention getTimer(), but we realize that our processing on enterFrame() has also degraded by 100 times. It is completely unacceptable for real world applications. Overall, this was the worst solution.

From what we can see, this performance degradation was surprise to you. Responsible teams don't work like this. I will not be surprised that Adobe even didn't optimize their code to make things better. I'm almost sure they didn't.

1000 times degradation.... My boss would fire me immediately if I let such crap going to the market!

[Robert Mc Dowell]

SergStone

although it's unacceptable we are all on the same boat of unacceptable things on this planet, And you know there are tons of it!

I just made some test on XP, 7, windows 10, linux 64 bits, OK yes everything is slower, even clicks reactions while  there is a getTimer in an enteframe loop, but the positive thing is everything takes twice less CPU.... . Anyhow, it's only the start of an Armageddon like, just an impression...

[Guest]

Thanks for the reply. Timer functions are used in the core event loop for the Scratch interpreter as well as in the "timer" blocks that are used by kids for a variety of projects. We are looking at ways to mitigate / work around this change, but it's currently a little unclear how to overcome such a drastic performance change to the common library.

[Robert Mc Dowell]

does getTimer() in 30fps loop will also affect the performance? if yes so it's really time to override this function asap

[Flipline]

Chris, is there a list of related APIs besides getTimer() that are affected by the Spectre/Meltdown mitigation?  It would be really helpful for developers to know what exactly has changed (and the speed impacts for each), so we have some reference of what we might need to update and avoid when we're seeing large performance issues in our projects.  I checked the release notes, but it only lists shareable ByteArrays under the Spectre/Meltdown notes, and doesn't mention getTimer() or anything else that might be impacted.

[arnoh78140517]

Hello, thanks for the insights. One question, does that imply that a timer jitter implementation causes that overhead? I think timer jitters have been introduced to JavaScript's performance.now() on all modern browsers several months ago as a reaction to Spectre, I cannot imagine that caused similar performance problems there, or a lot of websites would have suffered. Or what about invoking a low-resolution OS timer instead? (just some guesses without knowing implementation internals, so I might be wrong here)

Scratch is probably the largest user community using Flash those days (close to 30 million users). Wouldn't it have been an option to run an internal performance test together with the Scratch team before releasing such a breaking change?

Thank you!

[Robert Mc Dowell]

arnoh78140517  

pertinent suggestion, I would add if the real problem is micro second loop cycle instructions on CPU so why not to correct the root of the problem rather than disable functionalities widely used today and penalize millions of developers / users?

if it's the case so let's rewrite getTimer() with a gate that allows a certain time like 1ms, even if it's called several times under this lap..

forgive me if it's irrelevant but we need to understand clearly what's the Adobe staff problem to resolve this issue. If they clearly expose it, so the community can easily offer some solutions. million brains working together is  much better than a dozen.

[lemont79]

Flash 30 affects Ookla app running Flash badly.

On Flash 29, download throughput using Ookla speedtest for my 1gbps connection hits 760mbps, using Flash 30, it's only 258mbps.

Adobe please rectify this asap.

[Guest · Accepted solution]

Because of the changes by Adobe which increase the cost of `getTimer` and related APIs, we have deployed a patch that resolves the issue by reducing calls to `getTimer` and gets our performance back to where it was before the release of Flash 30 in most instances. If you are curious, details of the patch are available here:

Flash 30 performance changes by cwillisf · Pull Request #1396 · LLK/scratch-flash · GitHub

Timely assistance from Adobe (particularly in narrowing down the source of our problem) was most appreciated.

[chaosli]

how set EventJitterMicroseconds in android ,and ios,pls ,thanks

h

[_maria_]

Flash Player isn't supported on mobile devices, as such, there is no way to configure this setting mobile devices.

[chaosli]

hi,but the mobile devices,alos gettimer,slow.

how slove that?

thanks very mush

[_maria_]

As mentioned previously, Flash Player is not supported on any mobile devices, as such, there is no workaround to implement on the mobile device.

[chaosli]

But the GETTIME function on the phone is also a thousand times slower. Is there a way to solve this?

But the GETTIME function on the phone is also a thousand times slower. Is there a way to solve this?But the GETTIME function on the phone is also a thousand times slower. Is there a way to solve this?

[Test Screen Name]

But we said, you cannot run Flash on mobile devices. So what connection does this have with your problem?

[Flipline]

Are these timer changes/mitigations also present in Adobe AIR as well as Flash Player?  This may be what he's asking about, if mobile apps developed in Adobe AIR for iOS/Android are also experiencing slowness with getTimer.

[bentonh14088796]

Hi, Is the getTimer  performance fix in v30.0.0.134?  If not, which version will the fix be in or how do I find out?  Thanks.

[Test Screen Name]

This will not be fixed, it’s not a bug. The 1000 fold slowdown is deliberate.

[chaosli]

1000 slow,not bug?!

3

[Robert Mc Dowell]

Spectre / Meltdown Mitigations

Same story for javascript