Designing for Performance

• Performance oriented development
• Useful metrics
• Tooling
• Preferred practices

Performance oriented development

In general, embedded systems like an STB have limited memory and processor resources. Make sure that you take this into consideration when designing the service portal. Small pages and fast feedback will greatly improve the user-perceived performance.

Making a portal lean and responsive in an environment with limited system resources requires a careful approach to development. Assembling a nice-looking prototype on a PC and then running it on the box will often result in a very slow portal on the STB. Trying to work backwards to find out what is causing the performance issues is difficult at that point and it gets more difficult the more advanced the portal is.

Therefore, it is recommended to start with something very simple. Ensure that the bare minimum - perhaps just a single animated element - runs with good performance. After that, add functionality, animations, images, video etc. piece by piece and keep running frequent performance tests. The more frequent the testing, the easier it will be to identify what causes a performance degradation and work around it.

Useful metrics

Overview

Framerate (FPS)

FPS is a common performance metric in graphical applications. The value of keeping track of the FPS is that as long as the application can reach the targeted number, animations should appear smooth. This is particularly true if the targeted FPS is equal to the refresh rate of the TV (typically 50 or 60Hz). An application that manages to keep its FPS at the refresh rate of the TV is said to run at full framerate. Keeping an application at full framerate is a useful goal, since the subjective difference in animation quality between a full framerate application and a half framerate or variable framerate equivalent can be quite dramatic.

However, there are a number of issues with using FPS as a metric. The first is that FPS is nonlinear in relation to program execution time. If an operation is added to a portal that requires 1ms each frame to complete, the impact on the FPS will vary depending on how high the FPS was before the change. This can make it difficult to gauge the actual performance cost of a particular change.

The second issue is that FPS is typically measured as an averaged value over time. That can be useful for long animations, but when no animation is running, no new frames are produced by the portal. This means that FPS values for a non-animated portal will be highly misleading. Ensure that FPS is only measured when actual animations are running.

The third issue is that FPS is often capped to match the display rate of the display, which is typically 50 or 60Hz. The developer needs to be aware of this, since it means that the performance impact of a change will only be seen if the portal is running at less than full framerate.

Latency and frame time

Although measurements like FPS can give a good estimate for how a portal performs over time, it fails to catch short-lived performance problems that can be quite noticeable to a user. In particular, high latency and temporary slowdowns can be very annoying while being invisible to an FPS monitor.

Latency is the time it takes for user input to have a noticeable effect on the screen. Measuring it with high precision is difficult, but it's often sufficient to do subjective, manual tests.

Measuring the amount of time it takes to render each frame and keeping track of the worst case is useful for finding temporary performance problems that are experienced as hickups or stuttering. It's also useful since the frame time is directly dependent on program execution time, which makes it easy to use for estimating the performance impact of a particular change. At this point however, KreaTV supplies no tool for measuring frame time.

System and graphics memory

The environment in which portals are run is built to alleviate most of the concerns related to memory from the programmer. However, on an STB, memory is sufficiently scarce that care needs to be taken to avoid superfluous memory consumption. When the STB runs out of graphics memory, it may start allocating system memory which may result in severe performance degradation. When the STB runs out of system memory, it will crash.

Calculating in advance how much memory a portal will consume is quite difficult; there are many operations which may incur an unexpected memory cost. Therefore, it is recommended to closely monitor both graphics and system memory during development.

Tooling

Some metrics can, to some extent, be measured automatically in the portal code itself. For example, it's possible to use various clever techniques to monitor FPS in a portal environment. These techniques are almost universally bad. The main problem with this approach is that the measurement has a significant effect on the system that's being measured. Printing a line of text on the screen stating the current framerate may well become a bottleneck of its own and timers in Javascript lack the necessary precision to make framerate measurements.

Preferred practices

CSS and the blitter

Some combinations of hardware and platform settings allows for hardware accelerated CSS transforms using the blitter. A portal using only CSS for animation can, with care, be made to perform all graphical operations with the appropriate hardware instead of the CPU. This can result in significantly improved performance.

The blitter can only operate on graphics memory. Therefore, a hardware accelerated CSS portal will require more graphics memory to be able to render animations.

• Keep careful track of how much graphics memory the portal allocates and when it allocates it.
• Always test whether a particular transform is hardware accelerated when introducing it. The performance difference should be apparent.
• Always test changes made to CSS animations on the STB. It's difficult to predict how the browser will behave.
• Keep images that are part of an animation in graphics memory.

Garbage Collection (GC)

Since the portal environment includes a garbage collector, the developer needs to be aware that the GC will be invoked periodically. If the portal has created many objects (either in Javascript or in the DOM), the GC may incur a noticeable performance cost. Keep the following in mind:

• Keep the number of objects, both in the DOM and JS code, to a minimum.
• Avoid creating and destroying temporary objects when possible. Reuse old objects when possible.

DOM operations

The Document Object Model in the browser is a frequent source of bottlenecks. Recalculating the DOM layout, creating new objects or searching for existing objects are all quite expensive operations.

• Try to keep the DOM as small as possible at all times.
• Avoid functions that traverse the DOM (e.g. getElementById). It's better to keep track of objects in a JS array or similar.
• When possible, avoid changing the DOM while animations are running.
• When handling many DOM objects, try to reuse old objects when new ones are needed instead of discarding and recreating them.
• When possible, batch multiple DOM changes and perform them all in one go before any reflow-triggering actions.
• When doing extensive changes, consider cloning the base element of the change, do the changes on the clone, and swap it back once the change is done.
• It may be advantageous to hide an element with display: none while doing many changes and then restore the display attribute.