Skip to main content
A
Anonymous
June 7, 2018
Answered

Performance Issues in Flash 30.

  • June 7, 2018
  • 6 replies
  • 9030 views

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)

    This topic has been closed for replies.
    Correct answer

    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.

    6 replies

    T
    Test Screen Name
    Legend
    July 15, 2018

    No. Security fix.

    T
    Test Screen Name
    Legend
    July 13, 2018

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

    C
    chaosli
    Known Participant
    July 15, 2018

    1000 slow,not bug?!

    3

    Robert Mc Dowell
    Robert Mc Dowell
    Legend
    July 15, 2018

    Spectre / Meltdown Mitigations

    Same story for javascript

    B
    bentonh14088796
    Participant
    July 13, 2018

    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.

    C
    chaosli
    Known Participant
    July 10, 2018

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

    how slove that?

    thanks very mush

      _maria_
      Community Manager
      _maria_Community Manager
      Community Manager
      July 10, 2018

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

      C
      chaosli
      Known Participant
      July 11, 2018

      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?

      C
      chaosli
      Known Participant
      July 10, 2018

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

      h

      _maria_
      Community Manager
      _maria_Community Manager
      Community Manager
      July 10, 2018

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

      chris.campbell
      chris.campbell
      Legend
      June 7, 2018

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

      Chris

        chris.campbell
        chris.campbell
        Legend
        June 7, 2018

        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
          justtryme
          Participant
          June 8, 2018

          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

            Terms & ConditionsAccessibility statement
            Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices