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 - 184.108.40.206
Google Chrome (PPAPI)
Flash Version - 220.127.116.11
Google Chrome (PPAPI)
Thank you for the heads up. Our team has reproduced the issue and we're now investigating further.
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.
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
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.
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!
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...
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.
does getTimer() in 30fps loop will also affect the performance? if yes so it's really time to override this function asap
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.
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?
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.
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.
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:
Timely assistance from Adobe (particularly in narrowing down the source of our problem) was most appreciated.
how set EventJitterMicroseconds in android ,and ios,pls ,thanks
Flash Player isn't supported on mobile devices, as such, there is no way to configure this setting mobile devices.
hi,but the mobile devices,alos gettimer,slow.
how slove that?
thanks very mush
As mentioned previously, Flash Player is not supported on any mobile devices, as such, there is no workaround to implement on the mobile device.
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?
But we said, you cannot run Flash on mobile devices. So what connection does this have with your problem?
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.
Hi, Is the getTimer performance fix in v18.104.22.168? If not, which version will the fix be in or how do I find out? Thanks.
This will not be fixed, it’s not a bug. The 1000 fold slowdown is deliberate.
1000 slow,not bug?!