Olivier Le Moal - Fotolia
How to solve JavaScript and Java performance issues
Given the complexity of client side user interfaces, along with the often limited processing power of many mobile devices, finding out ways to address JavaScript and Java performance challenges is a priority.
Java and JavaScript are the most popular programming languages by most metrics, in no small part because they're widely taught and allow for rapid and stable development. But JavaScript and Java performance issues can become a challenge, so developers should be prepared to design for efficiency where it's required, and remediate where it's not achieved. To do that, be aware of the major Java and JavaScript performance issues, use observation and monitoring to pin down problem areas, look at some common problems, and watch performance carefully during change cycles.
Identifying JavaScript and Java performance issues
The biggest JavaScript and Java performance issues for modern applications aren't language-specific. Modern apps should be designed to be distributed, scalable, and resilient, and these properties are more likely related to how applications are componentized than how each component is authored. However, Java and JavaScript sometimes encourage practices that can result in major performance hits.
The biggest Java and JavaScript performance issue at the high level is inefficient distribution of processing tasks. JavaScript is most often used in application front-ends, as a means of making web pages interactive or adding presentation logic to server-side components of the application. Java is often seen as a true "virtual machine", with multi-threading and resiliency features built in. Both views can get you into trouble.
It's easy in JavaScript to push tasks to the edge, either to web servers that are part of the front-end, or into the user's browser. Where these tasks require I/O activity or where server-resident script engines process browser objects, you can end up with significant delays.
In Java, you have to remember that the JVM is an engine and not a form of cloud or distributed virtualization. Think of the JVM as a single server, and the applications as parallel tasks or programs. They all share server resources, and that means they compete for them. Don't neglect distribution of functionality in Java!
Anticipating Java and JavaScript performance issues
For applications already running, there's a broad consensus that the most important advice in application performance is to avoid trying to fix what isn't broken. Java and JavaScript performance issues, when manifest either in the form of user complaints or resource issues, should be addressed promptly, but it's rarely helpful to try to anticipate them. Wait till you see some symptoms.
Observation is the front-line tool in meeting JavaScript and Java performance issues. Online systems have distinct phases of interaction. Do the performance issues impact them all, or just a few? While it's possible that all of the elements of an application have the same problem or at least have some performance, issues, widespread performance problems more often indicate a problem with a common, regularly used, component.
Observation is also helpful in pinning down specific technical issues. In Java, for example, a common issue in application performance is inefficient garbage collection (GC). GC problems cause distinct hiccups in the progression of applications at the point where GC takes place, as opposed to a general slowdown.
Monitoring application performance
Don't start tweaking things based on observation alone. Some form of Java and JavaScript performance monitoring is essential in finding the specific problems. Start with generalized performance monitoring tools to see how processing time is divided between front-end and back-end elements, then move to isolating components that are creating delay, before you dive into code. Java monitoring tools are more readily available than tools for JavaScript. Stagemonitor, an open-source tool for Java, is particularly useful because it provides time-stamp analysis of distributed components. In JavaScript for browsers, most browsers will offer a development toolkit that includes a CPU monitor to identify which JavaScript elements are taking the most execution time. Depending on what server-side script engine you use, the same data may be available there.
Both Java and JavaScript have what could be called "classic issues" that should be looked at before you make any extensive changes to code. For Java, there are differences in execution performance between JVMs, so try benchmarking your application on several different ones, where available. For Windows, some applications will run faster on 32-bit versions of the JVM and others on the 64-bit versions. Finally, look at the JVM parameters, particularly those involving memory/stack management, to insure they're optimized for the kind of application you're running. Above all, consider running multiple JVMs where the JVM itself is a bottleneck.
Improving JavaScript performance with CSS
In JavaScript, users report that using CSS for things like automation and DOM manipulation is much faster than JavaScript, so you should explore that option with browser-based JavaScript performance issues. Also, avoid constantly relocating browser objects with script execution; store pointers to relocate things quickly. Database access (WebSQL) is also likely to cause performance issues, so consider pushing database activity back into a Java component or one written in another traditional language like C or C++.
All of this, users report, can be for nothing if you don't take care to sustain performance during application changes. Most companies are moving to continuous development and deployment, and many who do so are failing to provide adequate performance testing at scale. Developers know that the place where problems most commonly arise is in a change cycle, where time pressure and a focus on features can override awareness of performance issues. Don't let that happen.
An easy way to ensure that performance problems aren't in a change cycle is to do a final at-scale test of a application version and compare the results against the original version. Any noticeable performance difference should be addressed before the application is released to production. Another good idea is to do specific application performance monitoring during the week of operation of a application, just in case at-scale testing doesn't really replicate full production workloads.
Almost all high-level languages are less efficient than lower-level ones. For components of applications that will be exposed to very high workloads or that have to generate very short control loops, it may be advisable to "escape" into another language for development of these components. In many cases, this will resolve performance issues for the application at large, even if only one or two components are changed. The right answer is the one that works, not the one that's easiest!
