Node Count and JavaFX Performance
In a recent blog entry entitled Best Practices for JavaFX Mobile Applications (Part 2), Michael Heinrichs espouses that keeping the scenegraph as small as possible helps JavaFX applications perform optimally. Regardless what version of JavaFX you're using, this is sage advice. Having spent some time trying to create components for a scoreboard-like application, I was concerned over the amount of CPU time being consumed by the clock component pictured directly below.
You can download the code used in the preceding image to run this mini application via Java WebStart. By placing your mouse over any of the digits and typing in, via keyboard input, a valid number, you can set the clock. Clicking on the "START/STOP" text will toggle the clock on and off. Like many scoreboard clocks, when the time remaining is less than one minute, 10ths of seconds are displayed. It is during this phase, when digits are being updated every tenth of a second, that this application can be especially taxing. You can imagine how troublesome this clock might be if it were to be part of say a hockey scoreboard which could have an additional 4 penalty clocks ticking simultaneously.
The major factor affecting performance appears to be the sheer number of nodes in the scenegraph that require recalculation for every clock tick. For this first implementation, each of the five clock digits is comprised of 27 BulbNodes, (my naming) which are switched on or off depending upon what value needs to be displayed.
In an effort to see how decreasing the node count might effect performance, this second implementation of the clock component uses the same underlying framework, except that each digit is now composed of 7 LED SegmentNodes (my naming again) instead of 27 BulbNodes. You can run this second version of the clock component by downloading the code.
For our final example, in order to truly minimize node count, each digit is represented by a single ImageView node. When the value of a digit changes, a new Image is displayed. By caching all of the possible digit values (blank, 0-9) you can very quickly switch images. No doubt, prettier images can be created, but I think you get the point. Download the code to try this version.
The slower the compute platform, the more pronounced the differences in performance should be. Thinking along those lines, a very modest 1.4 GHz Pentium M laptop was chosen as the test environment to compare CPU utilization for these applications. OpenSolaris provides an easy-to-use well-known command-line tool called vmstat(1M), which was chosen as the mechanism to analyze the individual applications. In contrast, the Performance Tab which is part of the Windows Task Manager, seemed to produce wild performance variations.
For each run, the clocks were set to one minute, and run until the time expired. The data shown below represents the average CPU utilization, after startup, for each of the three implementations. In particular we'll look at the following fields returned by vmstat:
- us — percentage usage of CPU time in user space
- sy — percentage usage of CPU time in system space
- id — percentage usage of CPU time idling
The sum of (us + sy + id) should approximate 100%.
|Number of Nodes per Digit||CPU Utilization|
|Implementation 1: BulbClockNode||27 BulbNodes||us: 22% sy: 2% id: 76%|
|Implementation 2: LEDClockNode||7 SegmentNodes||us: 9% sy: 2% id: 89%|
|Implementation 3: ImageClockNode||1 ImageNode||us: 3% sy: 2% id: 95%|
The JavaFX engineering team is well aware of this limitation, and hopes to redesign the underlying scenegraph plumbing in the future. Regardless, it's still a good idea to take into consideration the size of your scenegraph.
Jim Connors, a long-time member of Sun’s system engineering community, has spent a decade helping customers leverage Java technologies ranging from Java Card and Java ME to Java EE and JavaFX. His new book, co-written with Jim Clarke and Eric Bruno, is JavaFX: Developing Rich Internet Applications (also available in Safari Books Online and as a downloadable eBook.
Editor's Note: This article was previously posted on Jim Connor's blog and is
Copyright 1994-2009 Sun Microsystems, Inc. Reprinted with permission.