Troubleshooting Player stability and performance

Trying to improve Adobe Flash Player in your browser? These tips may help. Nothing startling here, just a fast way of diagnosing things, proven in thousands of webforum postings…. ;-)

Stability

If you can make the system crash on demand, that’s much easier to fix than if it crashes only intermittently, unpredictably.

For instance, if you can never successfully view any SWF, or if it used to work fine but suddenly doesn’t, or if the installer didn’t seem to take, then try running the uninstaller to clear out any damaged packages on your system, then re-install afresh. This gets your Player code back to a known condition. If this was the cause, you’ll immediately know, because you’ll see Flash content again.

If a clean-reinstall still doesn’t let you view anything, then you’ll immediately know the Player code wasn’t the difference from similar computers, and that you’ll need to dig deeper into the system and its configuration.

Either way, a crash-on-demand situation is straightforward to diagnose. Just keep isolating one element at a time, until you can see where the core of the problem is. When you fix it, you’ll immediately know.

It’s harder to diagnose an intermittent failure, where things work well for awhile before crashing. Here are some fast tests to zoom in on the difference-that-makes-a-difference, the critical element required to make the system fail:

All pages, or just some pages? Can you view the Player Test Page normally? If it’s only a particular page which crashes the system, clear the browser cache of potential damaged assets. If it’s only a particular website which refuses to show its content, check its user-agent detection, its visitor requirements. If nothing works, that’s different than if only some things work… check the content to find the key factor.

All sessions, or just some sessions? It’s amazing how many problems are solved by just restarting the browser, or restarting the operating system. A fresh session may not solve the problem, but it’s a quick test to prove the system didn’t fall into a bad state.

All tasks, or just some tasks? If a failure only occurs playing an action game while watching a movie and having two dozen browser-tabs open, then that’s tip that the requested tasks are overwhelming the system’s capabilities. Graceful degradation is the desirable goal which is not always achieved, when the system is asked to do too much.

All browsers, or just some browsers? Microsoft, Mozilla, Opera Google Apple… each wants you to view The Web through their own brand of web-browser. Even the same browser brand can act differently loaded with extensions than when used in its original state. Take advantage of this variety — if the problem doesn’t appear in a different browser, you’ve quickly identified a cofactor.

All machines, or just some machines? Sometimes it helps to see how a similar system behaves, viewing the same webpage, the same browser. Ask a friend or a webforum if they can view the content normally in a similar configuration. If everybody else has the same problem, then you know it’s not just you!

These tests won’t always identify the problem, but are the fastest way to clear away large sets of potential causes. See the Player Support area for more.

Performance

If it’s hard to identify a crash, and harder to identify an intermittent crash, then it’s much much much much harder to identify the true factors responsible for performance differences…. ;-)

The first step is to get an idea of your system’s baseline performance, minimizing all other competing processes, removing all simultaneous distractions. Restart the system, use a fresh browser session and no background tabs, turn off any background notification systems or other tasks. See what the system can actually do.

If performance in a clean state is better than performance in the usual state, then that tells you to examine the effect of the other processes. If they’re both bad, then you’d know to compare the content to the system directly, and won’t have to worry about interference from other apps.

If you’re trying to improve baseline performance, vary the hosting software, vary the content, vary your settings:

  • Browsers differ in processing cycles they permit to plugins, and also interrupt those cycles under different conditions. Desktop applications (AIR, Projectors) are typically reported to run with less interference, faster. These differences are easier to see in a fresh session, without competing background processes. Vary the application which calls Adobe Flash Player to test whether this is the constraint.

  • Believe it or not, there’s some content out there which doesn’t quite follow best-practices. For example, check out these thousands of videos whose HTML requests wmode=transparent… piping the Player’s output through the browser for superfluous compositing will always be slower than writing directly to the screen, regardless of operating system. Make sure you’re not trying to optimize some content which has built-in problems. See if changing the content (both SWF and HTML) changes the performance.
  • Check your options, too… Adobe Flash Player is permitted to use hardware acceleration in some environments, reducing the load on the Central Processing Unit. Do a context-click on any SWF to call up its “Settings” mini-dialog to see what options may be available. Check your system’s display options, and whether your browser lets plugins use these.

But if your baseline performance is much better than your usual performance, then you’ve got to figure out how to prevent things from gradually going slow. Here are some of the top factors:

  • Background SWF: If you’ve got two dozen pages open, and each page has five SWFs, each trying to run at twenty frames a second, that’s 2400 frame events you’ve theoretically trying to execute each second. Different browsers choke off background pages in different ways, but they’re constrained by public desire to run video or audio in a background tab. If your performance bogs down midway through a session, cast a glance at how many SWF you’re running in the background, and whether reducing this helps performance. (The upcoming generation of Player 10.1 will help too.)

  • Background AJAX: This is an increasing problem, as more webpages include runtime elements. It’s harder to control this than SWF. Overall browser response is often the tipoff here… slow to switch tabs, slow to type, beachballs as the Macintosh reassigns memory. If you’re trying to regain baseline performance, cast a keen eye on what other tasks the browser is performing, perhaps without your knowledge. (And for goshsakes, be careful with those “HTML5″ demo pages!)
  • Too many things on each page: If your system slows down after too many webpages, try reducing the number of things each page does. Flash blockers, Ad blockers, JavaScript blockers, third-party monitors — all are great tools in a world where webpages have ballooned up past a hundred HTTP requests, invoking scripts from half-a-dozen domains. If the content is overwhelming the system, you can put those pages on a diet.
  • Widgets, toolbars, messaging systems, taskbar alerts, background updates, music players, typing utilities… there are many additions which can affect system performance. This is why that initial test in a clean condition is so important… it lets you compare your system’s true capabilities.

Performance is never good enough, but if you’re worried you’re not getting all you’re entitled to, the above tests are some of the faster ways to either fix it or identify it. If there’s even one person who can get good performance out of your general type of configuration, then you should expect to get that same good performance too.

(Sidenote on CPU % : Don’t stress the numbers much… they mean different things across operating systems, and having extra CPU cycles in the bank doesn’t offer much benefit. Keep an eye on whether the chip is running hot for the case, however… the fans mean more than the meters. Same with OS crash reports which mention the Player, which often happens when the browser fails to handle a plugin memory request. The numbers mean less than the behavior.)


Tue Feb 2: This is a first draft, and I plan on editing-in-public over the next few days. Comments probably won’t be published (considering history and current weather ;-) but if you’ve got a user-oriented tip I’ll definitely read it, thanks.