Adobe 23 & 24: Out of memory errors and performance issues

Flash Player is effectively a language runtime.  We process and run code written by developers.  Some of that code is for the actual content, and some of it is for advertising and analytics.

We also process code that's written by malicious actors, and we constantly harden Flash Player to prevent those actors from being able to use Flash Player as a vector for malware.  Any time an application does more processing, it consumes more CPU cycles.  While we design mitigations with efficiency in mind, they're never free, and that cost accretes over time.

There's no magic "make it faster" button that we can push to make things suddenly work faster.  It's very unlikely that we've injected an egregious performance problem at the language level.  It's much more likely that you're running across a specific, pathological piece of content that is either doing something very inefficient that was borderline passable before, but is now not, or there are a very specific set of circumstances that are in play that are slower.

That said, it's impossible to have an actionable conversation about performance without discussing the specific content in question.  In your scenario, you're talking about four concurrent windows loading arbitrary content, any of which might have one or more ads that also rotate.  Because advertising is highly targeted, it's quite possible that the problem is specific to an ad that you'll see, but we won't.

While we're always interested in performance issues, we have to get specific enough that it's actionable.  We've engaged in exercises in the past where we've identified slow code through high-end optimization tools, only to find that there's actually no discernable difference in performance in real-world content.  It's not enough to just optimize stuff (and in a 2.5 million line codebase, there's a lot of "stuff") -- you have to optimize the right stuff, and do it in a way that it still works across all of the supported platforms and millions of pieces of existing content.

The real productive discussions about performance happen between us and developers.  In general, the performance problems usually come down to poorly written content (ads, and ad-insertion code by smaller ad networks are frequent offenders), and we provide performance profiling tools that allow developers to identify and fix slow code.  The productive discussions about performance are centered around APIs... calling a particular API is 30ms slower per call, stuff like that.  In order to make it actionable, we have to get down to the discrete, atomic thing that's slow.  The notion that random is slow on the Internet isn't going to lead to a fix.

It's also possible that it's not actually something slow in the code.  It could just be that something takes a little bit more RAM, but it was enough that it exhausts the physical RAM on the machine, or that we've changed the layout of how memory is used on the system (this is one of the many strategies use us against malware authors), and memory fragmentation leads to memory exhaustion because some portion of physical RAM isn't writable in a useful way.  (In either scenario, throwing more RAM at the problem would help)

So, the goal, if you want to actually get down to actionable problem, is to strip it down to something specific that can be looked at.  It's annoying, but this is engineering, and precision is central to getting anything done.

I'd start by ruling some stuff out:

- Does using an ad-blocker make the problem go away?  If yes, it's probably an ad, or the activity generated by all of the content and ads you're viewing in aggregate is enough to push the machine over.

- Where's the resource contention?  When the machine begins to perform poorly, what does the CPU usage look like?  What does memory usage look like?  Is there high disk activity (indicating that the machine is out of physical RAM, and swapping lots of memory to disk -- which is literally ~100k times slower than operating in physical RAM)

- Once you know what kind of resource contention you're looking for, when running the content that you care about in isolation (a single tab), can you identify a piece of content that shows a large delta between Flash Player 22 and Flash Player 24?

- If so, then we at least know what piece of content to look at to begin understanding *why* the usage is higher in that scenario, and to determine whether or not it's intentional, and/or could be improved without weakening security mitigations or introducing side-effects.

- Do you have the same problem running the same content in other browsers?  Does the same 4-tab configuration in Chrome, Firefox or IE have the same problem?  They're very different pieces of software.  That would tell us whether it's in common code, or if it's related to some platform-specific code.