Performance Zone is brought to you in partnership with:

Jim has posted 16 posts at DZone. View Full User Profile

Node Count and JavaFX Performance

07.17.2009
| 9866 views |
  • submit to reddit

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.

From http://blogs.sun.com/jtc

Published at DZone with permission of its author, Jim Connors.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Andrew McVeigh replied on Fri, 2009/07/17 - 8:26am

that's odd.  i haven't used the javafx scenegraph, but i have lots of experience with the jazz scenegraph (from HCIL) which can cope with literally many thousands of nodes.  it uses efficient internal structures to avoid redoing nodes in the scene which haven't changed.  the nodes in the graph don't check themselves, something else has to adjust them.  in this case i'd use a timer with 1sec resolution.

wouldn't the scenegraph then only have to change per second, and for most seconds (i.e. 9 out of 10) only a small % of dots would adjust?  even in your 27 bulb per digit example, changing from a 2 to a 3 only involves 6 nodes altering.  i'm pretty sure i could display hundreds of these clocks under Jazz/Piccolo with virtually no CPU overhead, even if each clock had its own timer.

i wonder what's different about the JFX model that causes it to use lots of CPU?

Coffee Jolts replied on Fri, 2009/07/17 - 2:30pm

The longer JavaFx goes without a new scenegraph, the less likely it is that we will ever see one. Watching the team build more and more features on top of mud is just painful to watch.

Otengi Miloskov replied on Fri, 2009/07/17 - 9:00pm

Thats why all the client side stuff that does Sun blows and sucks. Look at Swing/AWT in the past, it gave a bad name to Java with the slow thing and crappy.

The more soon Oracle drop and kill JavaFX is the better for Java and the JVM. JavaFX with its scenegraph is AWT/Swing all over again.

 Oracle please, Kill JavaFX once for all!.

Osvaldo Doederlein replied on Sat, 2009/07/18 - 3:46pm

Before you keep whining, notice that Jim's blog is dated April 6th and it's specific to JavaFX 1.0/1.1. I also reported bad JavaFX scalability to large node counts in my blog in january. But this scalability issue is solved in JavaFX 1.2, as I report again in a recent blog.

Hint to editors: don't ever recycle an article that was written before the latest release of JavaFX. The JavaFX runtime is still maturing quickly, and the dev team is NOT ignoring the most pressing problems to only focus in new features. My personal impression is exactly the the opposite. So, when you write an article criticizing JavaFX's performance or other problems, your article usually becomes obsolete in the next major update.

Of course when the low-hanging fruit are over we just move up to find other stuff. In the last blog quoted here, I identified other performance problems - reported them to the JavaFX JIRA - a much less severe bug than the node scalability issue, but it's already commited for fix in the next major release. (Don't thank me, that kind of problem would probably be addressed anyway as a side effect of Prism, which is the next rev of the rendering engine that will be capable of limited 3D and probably other cool stuff. But IMHO, at least I proveded a nice test case / benchmark for some upcoming improvements.)

My latest JavaFX Balls 2.2 benchmark, for JavaFX 1.2, can animate 128 nodes at fixed 60fps with ~2.5%CPU usage. Note that this benchmark is not very real-world, it's rather a worst-case scenario because (a) the entire screen is animated at every frame, (2) every node moves frenetically at every frame, (3) almost all nodes are visible, at least partially, in every frame. This screws up with common optimizations like dirty rectangles and culling. In a more real-world program, e.g. a 2D action game (e.g. platform) - where only some nodes are animated at each frame; some groups of objects don't animate relative to each other (so you can benefit from cache:true on the group); and many nodes may be not visible for some reason, I believe that JavaFX can handle many thousands of nodes with small CPU usage... or many, many, many thousands of nodes with CPU usage that's still viable in most desktops.

Jess Holle replied on Mon, 2009/07/20 - 6:42am

Also JavaFX's graphics pipeline is being revamped for the next release.

Osvaldo Doederlein replied on Mon, 2009/07/20 - 9:27am

Yes, and in next releases, javafxc should also have important footprint optimizations. Umbrella: remove intermediate Locations from bind translation should be available soon in 1.2.1, and Umbrella: Slacker Binding is scheduled for the next major rev. Both are groups of optimizations for bound variables, a feature that has a big cost in heap usage, often even for variables that are not bound, e.g. any public field seems to need those "Location" objects just in case the app loads another class that binds to it. These bugs are in principle language/compiler issues and not runtime issues, but in practice, they can have a large impact in the system's overall performance and scalability (at least in some worst-case test scenarios) due to the costs of allocation, GC, CPU cache efficiency, and blocking JIT optimizations that could benefit more compact generated code.

Otengi Miloskov replied on Mon, 2009/07/20 - 2:48pm

But if we compare Flash/Flex with JavaFX, JavaFX still ages to go. To download the plugin is 10mb compared to to flash is 1.80mb and silverlight 3 4mb. So JavaFX still so bloated. also Flash and silverlight 3 support shaders and gpu acceleration, where is JavaFX?. Silverlight is xml nothing new to learn, flash is AS==javascript nothing new to learn. JavaFX is a complete new programming declarative language with lots of keywords and constructs and kind of weard syntax. JavaFX always have bugs with applets, I have to start the demos with webstart because as applets hang or crash the browser. Im talking about JavaFX 1.2 here. Also where is JavaFX future?, Oracle hmm... they could say anything in JavaONE but it could happend anything we know how are the proprietary enteprises so why invest in something that does not have a future and it is the crappiest of all the solutions.

I dont see what brings JavaFX new to the table. Again I hope Oracle quickly kill JavaFX and stop this madness of crappiest tool hype.

Osvaldo Doederlein replied on Tue, 2009/07/21 - 10:49am in response to: Otengi Miloskov

Silverlight 3 is indeed a 4.8Mb download, at least for Windows. The MacOSX download is 8.7Mb; and Mono's Moonlight for Linux, even at Silverlight 2 (preview) level, is even bigger at 9.2Mb. The Windows download is only that small, very likely, because it can rely on some stuff that's already part of Windows (DLLs from MSIE, DirectX, Windows Media etc.). So in fact, Silverlight 3 is not a ~5Mb runtime; it's a ~10Mb runtime but Windows users already have half of it preinstalled. Additionally, sophisticated Silverlight or Flash apps are likely to have extra dependencies; both platforms offer extension libs, like Flex or Silverlight Toolkit, that add extra APIs... including such SL3 highlights as its charting package. Some packaging tricks here to disguise the real size of these platform.

On the other hand, JavaFX depends on the JRE which adds extra Mb.  But then, JavaFX is a much richer platform precisely because you have the complete Java SE runtime below it (or full Java ME / MSA, for JavaFX Mobile). In contrast, Silverlight 3 includes a subset of the .NET platform; many APIs are not available, and the CLR VM is also much slimmed down so I guess its performance is significantly inferior for CPU-bound code (i.e. any app that relies a lot on its own bytecode, not on the runtime's services). And the JavaKernel makes JRE/JavaFX's "cold installation" much smoother, although this can still improve (only the modularized JRE 7 should deliver a really optimal download/installation experience).

JavaFX is fully GPU-accelerated. And it uses shaders for the Effects framework although this is a limited feature compared to general exposure of HLSL like in Silverlight 3. OTOH, Effects have a more general shading framework that's capable of using D3D or OGL shading, or CPU/SSE, or software as a last resort, complete with a single shading language that works for them all (imaginatively named Java Shading Language). Unfortunately this is so far "implementation detail" but I hope Sun is smart enough to promote this to a public feature. Which may be likely considering that next release will have some level of 3D support and a revamped graphics pipeline (Prism). If JSL goes public, JavaFX will be ahead of the pack, and not too late (Silverlight has HLSL only since v3, which is just recently released.)

"Silverlight is XML nothing new to learn", that's bollocks, XAML is a pretty complex XML language; or, in other words, it must be filled with objetcs from a pretty complex framework. It's easy to read, but not easy to write without training. For simple apps that can be fully programmed in XAML, JavaFX Script is just as intuitive if not better (much cleaner syntax than XML). For more complex apps Silverlight requires C# or other real language while JavaFX requires nontrivial JavaFX Script (i.e. not just trees of scene graph nodes) and although the latter requires some learning, it's then easier because it's a dedicated UI DSL. And don't get me started on JavaScript/AS3, it's just junk, the world is already a bad enough place with the Web platform imposing the JavaScript mess (although that's IMO).

Otengi Miloskov replied on Tue, 2009/07/21 - 3:50pm in response to: Osvaldo Doederlein

@Osvaldo thanks for your response, after your post I was thinking about JavaFX and it seems JavaFX background is not pretty bad as you said it and you are right about Silverlight in windows some components are already installed but other platforms it is a huge download. About Javascript Im with you too I now use javascript and AS with Flex but it is a pain sometimes, messy, before I didnt want to learn Javascript but I had to do it.

I think you are right I have to test more and do some projects with JavaFX maybe I will like it but The only thing is if really Oracle will support it, I dont want to just learn something and tomorrow someone told me Oracle killed the project, thats why I said I hope they just kill it quickly before it gets popular and we begin to depend of a technology that meybe they could kill it anytime soon or later. But after your comment it looks that JavaFX is interesting and the prism stuff. well, lets see how it goes.

Thanks.

Osvaldo Doederlein replied on Tue, 2009/07/21 - 8:05pm in response to: Otengi Miloskov

The Oracle buyout is indeed, still a factor of uncertainty, not just for JavaFX but for any Sun technology that's not yet very entrenched. At the JavaOne keynode, Larry Ellisson appeared and praised JavaFX very specifically so that gave the JavaFX project and community a good breath of fresh air, at least for some time. I wouldn't completely rule out the possibility of Oracle killing JavaFX, just because Larry went there to pay some lip service (certainly by request of Sun). Let's wait and see.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.