Last week, I wrote about pausing animations in OpenLaszlo applications when they’re not visible, to improve runtime performance, and I promised to elaborate on what the other areas of performance tuning were. This is a good time to cover areas of optimization at a high-level. People sometimes mis-categorize performance problems with Rich Internet Applications (RIAs), because RIA development introduces new development paradigms. e.g. Developers may say “my app loads slowly”, when they actually mean that the startup time is poor. It’s important to correctly understand what you’re trying to improve.
There are four distinct areas of performance-analysis that apply to OpenLaszlo applications (as well as just about any RIA – Flash, DHTML/AJAX, Flex, etc.):
- Application Size
- Startup Time
- Runtime Performance
- Memory Consumption
Application Size refers to the size of your application. With a SWF-compiled OpenLaszlo app, that’s the size of the SWF, measured in bytes. It’s very easy to find this out – you can look at the Developer’s Console, or the compiled SWF in your filesystem. The size of the application, the end-user’s connection speed and caching all affect the user-experience.
The size of any RIA is generally larger than an HTML page. This should not be cause for concern. Firstly, RIAs compensate for their larger initial download with reduced traffic while the application is running. In an RIA, only XML data are transferred when communicating with the server; in an HTML application, entire HTML pages (including some images) are reloaded virtually every time the user performs an action. Secondly, web browsers will cache SWF content by default, so users will typically only have to wait for an OpenLaszlo application to download once.
Startup Time is the time taken for an application to initialize. It begins after the application is fully downloaded. Startup time can vary based on the application’s complexity, the speed of the client computer, and (possibly) on network speed. Since applications initialize every time they are accessed, there’s no caching. There are two phases of startup time that apply to most RIAs: Normal startup time and late initialization time.
- Normal startup time begins when the application has finished downloading and in an OpenLaszlo application ends when the canvas sends the oninit event. i.e. When all the views that are instantiated normally are completed.
- Late initialization time begins when normal startup time has ended, and ends when the application reaches a steady state. The steady state could be a login screen, or if a session already exists, it could be the application with all its data displayed. This includes the time taken to make any initial HTTP requests and render any views that are bound or replicated to the data.
Runtime Performance is the most subjective area of performance tuning. It refers to the general feel of the application after it has started. Quantifying runtime performance is tricky. Firstly, defining what part of runtime performance you’re analyzing is imprecise (e.g. “this window takes ages to open”). Secondly, measuring how long a particular view takes to display often involves either diving deep into the code, or relying on an inaccurate method, such as a manual stopwatch. The factors that affect runtime performance include complexity of the application, idle load on the CPU, data size and network speed.
Memory Consumption relates to an application’s memory footprint on the client. Generally with RIAs, the concern isn’t how large that footprint is, but that it remains contained as parts of the application are enabled and disabled. Since RIAs run inside of a web browser and browsers don’t publish how much memory their runtimes (e.g. Flash/JavaScript) are consuming, you have to rely on the Operating System to tell you how much memory is used by the browser as a whole. Moreover, browsers aren’t all equal – some (like Firefox) are a little more “loose” with memory allocation, and there’s no way to trigger the garbage collector (in Flash/JavaScript) manually. You may create an object in your application, see the memory consumption increase, then destroy it, and see no immediate decrease. Thankfully OpenLaszlo has some neat tools for tracking “lost” objects that could result in memory leaks.
These areas of performance tuning affect each other. You can improve startup time by deferring the initialization of some objects, but that essentially leads to degraded runtime performance. (Which may be a perfectly acceptable trade-off). Poor memory management may not be a problem in an application that’s only used for brief periods, whereas it could eventually result in poor runtime-performance in an application that’s used for a longer period of time.
Stay tuned for more tips in this series, and look for a note on what areas of performance tuning each tip may affect.
