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 click on 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 version of the clock component by clicking on the image that follows.


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.  Click on the image that follows to try this version.


The Results

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.

JavaFX book status:  Our upcoming book, JavaFX: Developing Rich Internet Applications, is in copy edit.  Coming soon: Rough cuts of certain chapters will be available on Safari.

Comments:

One point: you may want to try your experiment on a system with better video board (relatively recent nvidia or ATI). On your machine with integrated adapter everything would have been ran in sw, no hw acceleration.

Dmitri

Posted by Dmitri Trembovetski on April 07, 2009 at 09:47 AM EDT #

Clock example very strange work under Linux.
(<01:10:49> ~: java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode))

Posted by Leonidv on April 08, 2009 at 07:41 PM EDT #

As per these first two comments:

(1) Dmitri suggests running on better hardware taking advantage of hardware accelerated graphics. This will absolutely help. What I was interested in pointing out though is that resource challenged devices (i.e. JavaFX mobile?) might have issues with this, thus the usage of the older system.

(2) Problems running applications on linux. Yeah, I've seen all types of wierdness on both Linux and OpenSolaris, depending upon all sorts of variables, including JRE version and hardware graphics capabilities. The unfortunate reality right now is that your best bet is to stick with either Windows or MacOS.

Posted by James Connors on April 09, 2009 at 06:23 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Jim Connors

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today