Performance matters - 25x for JavaFX script over Groovy and JRuby

JavaFX script

function tak(x:Number, y:Number, z:Number): Number {
    if (y >= x) z else tak(tak(x-1, y, z),
                           tak(y-1, z, x),
                           tak(z-1, x, y));

for (i in [1..1000]) {
    tak(24, 16, 8);
time javafx -server -cp . Tak

real    0m10.724s
user    0m10.105s
sys     0m0.173s
def tak(double x, double y, double z) {
    return y >= x ? z : tak(tak(x-1, y, z),
                            tak(y-1, z, x),
                            tak(z-1, x, y));

int i = 0;
while (i++ < 1000) {
    tak(24, 16, 8);

time java -Djava.ext.dirs=./groovy-1.6-RC-1/lib -server groovy.lang.GroovyShell tak.groovy

real    4m36.674s
user    4m29.272s
sys     0m3.842s


def tak x, y, z
  unless y < x
    tak( tak(x-1, y, z),
         tak(y-1, z, x),
         tak(z-1, x, y))

i = 0
while i<1000
        tak(24, 16, 8)

time ./jruby-1.1.6RC1/bin/jruby -J-server tak.rb

real    4m24.735s
user    4m22.203s
sys     0m1.069s


For this benchmark, as you can see both JRuby and Groovy are around 25x slower than JavaFX script.


Not terribly surprising, considering JavaFX is compiled to bytecode (with some variable overhead due to binding that is probably not horrible).

Posted by Jose on January 02, 2009 at 10:40 AM PST #

Yet another completely useless microbenchmark.

Posted by guest on January 02, 2009 at 11:19 AM PST #

In JavaFX 1.0 doesn't JavaFX Script run exclusively in the EDT? Why would I want to spend 10 seconds in the EDT freezing the GUI to calculate numbers?

Posted by Danno Ferrin on January 02, 2009 at 11:29 AM PST #

@Danno Ferrin

Takeuchi is a simply function call performance benchmark.

And FYI JavaFX script itself knows nothing of the so-called EDT. That it simply an artifact of the current desktop runtime implementation of the scene graph APIs.

Your link indicates you have some personal attachment to Groovy.

In spite of whatever your personal feelings are, it's quite undeniable that Groovy and JRuby sacrifice an order of magnitude or more performance-wise compared to Java and JavaFX script.

In my opinion, that's poor and unacceptable.

Posted by Chris Oliver on January 02, 2009 at 12:03 PM PST #

First, the comparison is between Groovy and Ruby. JRuby happens to be one of the many implementations of Ruby (Ruby is open source soup to nuts so such details are permitted by it's license).

Second, this is just the age old comparison between runtime dispatch and compile time dispatch. The reason that Ruby and Groovy does it has to do with what they aim to accomplish. Take GORM for example, you can throw any random query method at an object that follows a particular pattern and have it resolve it at runtime. Can't do that in FX Script (or Java, or C). There are gigabytes relating to the dynamic vs. static discussion on the internet and Usenet forums, so enough said.

To criticize a language without taking it's aims into consideration is, in my opinion, poor and unacceptable.

Posted by Danno Ferrin on January 02, 2009 at 12:26 PM PST #

It's not really a comparison of apples to apples here:

\* The JavaFX version is probably using primitives. Groovy and JRuby are using boxed numbers. So this becomes more of a boxed number allocation/GC benchmark than anything else.
\* The JavaFX version is doing direct static dispatch. Groovy and JRuby are doing dynamic dispatch. Groovy may also be using reflection and boxing the argument list.

Those same features that damage numeric performance also enable features Java and JavaFX don't have. And let's also not forget the relative sizes of JRuby and JavaFX teams over the past couple years. We've done a lot, considering.

Ultimately these kinds of numeric algorithm comparisons are just noise. There's plenty of other comparisons that could go to JRuby or Groovy, and there's features each language has that the others don't. So what? Unless you're trying to outright insult the folks who have put a lot of work into JRuby and Groovy, or the people who find their performance acceptable for the applications they write, there's little point in publishing a post like this.

Spend your effort continuing to improve JavaFX, help JRuby and Groovy improve their performance, or help ongoing JVM work that will aid us all. Sabre-rattling is unbecoming.

Posted by Charles Nutter on January 02, 2009 at 01:06 PM PST #

JavaFX Script may know nothing of EDT by itself, but surely its interpreter does, or how would you explain this?

[aalmiray@localhost tmp]$ cat Tak.fx
import java.lang.System;
import javax.swing.SwingUtilities;

function tak(x:Number, y:Number, z:Number): Number {
if (y >= x) z else tak(tak(x-1, y, z),
tak(y-1, z, x),
tak(z-1, x, y));

System.out.println("Am I running on EDT?? {SwingUtilities.isEventDispatchThread()}");

for (i in [1..1000]) {
tak(24, 16, 8);
[aalmiray@localhost tmp]$ javafxc Tak.fx
[aalmiray@localhost tmp]$ time javafx -server -cp . Tak
Am I running on EDT?? true
12.11user 0.09system 0:12.27elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1major+10207minor)pagefaults 0swaps
[aalmiray@localhost tmp]$

Posted by Andres Almiray on January 02, 2009 at 01:46 PM PST #

How does JavaFX compare to JavaScript running on Google's Chrome or Apple's Safari? How does it compare to ActionScript in Flash? Or Microsoft's Silverlight? I posit that these are your real competitors, not Groovy or JRuby.

You also chose to write an incredibly recursive function to spend a huge amount of time dispatching function calls with stack frames, whereas I suggest that a "typical" program might "do useful stuff" instead (e.g. most Rails programs, most ActionScript programs, etc.)

But congrats on delivering a clean elegant language to finally give Java attractive interfaces that most people can create and enjoy. JavaFX is definitely a client-side improvement it needs to be pushed hard before it loses to Silverlight and AIR. I hope you're able to make it work on cell phones in H1 2009.

Personally I use JavaScript on the client and Perl CGI on the server because they are always there for me, they do what I want them to do, and they perform well. Each to his own, right?

Posted by Kevin Hutchinson on January 02, 2009 at 02:14 PM PST #

Just for kicks I did a comparison with Scala too: . Scala was faster on this benchmark than JavaFX. Not surprising really, just like it wasn't surprising to see JavaFX faster than the dynamic languages.

Posted by Michael Galpin on January 02, 2009 at 02:59 PM PST #


Personally, I feel it's valuable, on the one hand, to demonstrate the hard work the JFX compiler team has put into performance. It certainly seems from benchmarks like these that the investments in the compiler have paid off.

On the other hand, I think both the title of this posting, as well as the tone, are not welcome. It really feels like you're picking a fight. I'm sure you could approach this issue (which you feel is important) more tactfully and therefore avoid burning bridges with the wider languages community.

It is true that some members of other language communities have been launching potshots at JFX for many months now, declaring it irrelevant and showing what they can accomplish using e.g. Groovy, JRuby, etc. I think the tone and attitude has been pretty poor all around.

Personally, I'm less concerned with raw performance on these kind of micro-benchmarks than I am with performance of the scene graph and rendering engine you're using. Outside of the video demos (which are impressive!) I haven't been blown away by any of the demos for JFX 1.0 that have been posted, when looking at performance.

In the end, I'll be won over to your cause as I see better, higher-quality, more performant demos of what your software can _do_.

You've been a good advocate for F3 and JFX in the past; please avoid the food fights, it doesn't suit you or your cause.


Posted by Patrick Wright on January 02, 2009 at 08:59 PM PST #

JavaFX is neat and all, but where is Rails for JavaFX? You give a performance benchmark, but you don't compare against Java. In Groovy (not sure about JRuby) I could easily rewrite the above code as a Java class, \*if\* /real/ performance testing showed that that section of my application code was CPU bound, and easily resolve any performance problems. Which I have time to do, thanks to all the time I saved using Groovy (and Grails).

New languages without many users really shouldn't throw stones.

Posted by noah on January 02, 2009 at 10:56 PM PST #

I personally prefer lower performance to the bad language design. Performance can be fixed, language design not.

I have yet to find a reason why to use JavaFX as a language. The bind mechanism is not that great when it comes to something more than the school examples. I also consider the bind mechanism as a potential bottleneck, as a single change of a variable can cause many update calls. You guys need to look at the lazy implementation of bind, the current one is simply too eager.

This is where you should focus your effort, not the cheap benchmarks as the one above.

Posted by John Silver on January 03, 2009 at 12:40 AM PST #

The rationale underlying this post (and others on this blog) is simply the following: one of the most significant features of the Java platform and factors in its success (if not the most significant tbh) is the performance of the Hotspot VM.

This fact is ignored at your peril.

But, as the comments to the this post show - it's nevertheless commonly and easily glossed over without justification.

The performance differences between JVM languages like Java, Scala, and JavaFX script, which are able to exploit Hotspot, and those that currently cannot are real and quite extraordinary (by any measure), and not simply to be ignored. And the same can be said (and is said elsewhere on this blog) of other languages that target lesser VMs.

If you're observant of this blog you'll also be aware that graphics and animation performance depends on additional factors in addition to VM performance, namely GPU hardware acceleration, which equally is not to be ignored - and isn't - at least here.

Posted by Chris Oliver on January 03, 2009 at 01:28 AM PST #

@andres almiray

As I already said that's simply an artifact of the current desktop runtime implementation - which also explains the excessive startup time for non-graphical JavaFX code such as this benchmark - i.e. class loading and shared library loading of the AWT.

This is also why a pure Java or Scala implementation of this benchmark is slightly faster.

It's possible to configure the JavaFX script runtime to avoid this - the code is open source - take a look yourself, if you like.

Posted by Christopher Oliver on January 03, 2009 at 02:45 AM PST #

The fact that Java, JavaFX, and Scala benefit from Hotspot is obvious. But you're completely ignoring the fact that Groovy and JRuby and others also take great advantage of Hotspot. In JRuby's case, we are now the fastest Ruby implementation with a lot of runway to continue improving. And we work every day to make Ruby code more optimizable by Hotspot. We are not, as you put it, ignoring Hotspot...we are actively exploiting it, and performance improves with every release.

I also recall a time when JavaFX had absolutely dismal performance. The fact that it required a very large team of developers working for over a year to bring it to this level of performance says a lot about the amount of effort required. A similar amount of effort expended on other JVM languages could produce similar results.

The the performance challenge facing an implementation like JRuby is completely different from that facing languages like Scala or JavaFX, both of which largely conform to the JVM rather than push it in new directions. If this platform is to survive, it needs to be able to host languages that may not have been explicitly designed for it, and enhancing the JVM to support such languages (through such work as JSR-292) will better the platform for us all. Either you have not considered this aspect, or you're willfully ignoring it. I hope it's the former.

With so many VMs jockeying for developers, your post does little more than alienate the same people working side-by-side with you to make Hotspot and OpenJDK the premier language platform. You insult the efforts of language implementers that don't subscribe to your worldview. You ignore the enormous potential of the JVM as a host for many languages, including languages exposing current weaknesses in the platform. And perhaps worst of all, you frustrate the efforts of many Sun colleagues trying to reach out to language communities by posting a petty, offensive blog post.

You're right...we have an amazing platform and an amazing VM here. Perhaps we should work together to ensure it succeeds, rather than kicking each other in the teeth.

Posted by Charles Nutter on January 03, 2009 at 03:36 AM PST #

@Charles Nutter

I'm well aware of the technical reasons for the performance discrepancies mentioned - however those facts do not change the current reality from a user-point-of-view.

You can take it as insult if you must, but it's not my doing that you feel that way.

The simple fact is that in the problem domain JavaFX is targeting (world-class multimedia), C and C++ are still the real (and very tough) competitors.

Current incarnations of Ruby, Groovy, JavaScript and similar languages are simply not-even-close-to-viable in this problem domain.

Making JavaFX script and the Java platform viable is itself no small task.

From some 10,000 foot view, it's easy to say one can use "any programming language", "any platform", "any vm", "any graphics stack" - and this is heard all the time.

However, the factual reality is that in today's day and age that's not actually the case.

At the end of the day it's the performance observed by the end-user that separates the "wheat" from the "chaff", when it comes to software platforms.

I'm not sure if you've heard of him, but in the domain of graphics and animation our real boss is a dude named "Mr. Frame Rate" - and he's a very harsh master. Do a couple of things wrong and he will deal you a very harsh penalty, which is immediately observable to every single one of your users.

It's "his" opinion that matters - not mine.

Posted by Christopher Oliver on January 03, 2009 at 04:14 AM PST #

So you are right when you are saying that Frame rate is the king for your field of application, but... this benchmark is not about rendering ;-)

I follow the (amazing) efforts of both JRuby and javaFX, and I think that these two projects do not have the same users use case. javaFX compete against Flash and Silverlight, right ? So it's problem is to have an acceptable framerate for graphic intensive application, on the client? On the other hand, JRuby is working well on the server, or is perfectly suitable for configuration or various scripting purposes (just to name some examples). I really value JRuby, but I would really never use it for graphic-intensive computations. On the other hand, I would never use javaFX for server-side (at least for the moment).

Please note that I'm not pro-JRuby or pro-javaFX, I want (and now I have) a fast and scalable open-source implementation for the Ruby language, and I want a fast and scalable open source RIA-enabling framework. Maybe I'm close to having it now ;-)

Posted by Hervé on January 03, 2009 at 06:02 AM PST #

Ahhh, Chris Oliver. I see you are still the opinionated, obnoxious jackass I remember from the SeeBeyond days.

Some things never change.

I, for one, will NEVER even explore JavaFX because of your affiliation with it.

Good luck.

Posted by Hank on January 03, 2009 at 06:04 AM PST #

Hope you got written permission from Sun before publishing your benchmarks as per the JavaFX licence.

Posted by Richard Osbaldeston on January 03, 2009 at 06:59 AM PST #


Tbh, I don't remember you.

Yes, I'm opinionated, however I haven't made any personal attacks here.

Yes, I can dish it out, but I can also take it - which is why I'll leave your troll for posterity.

JavaFX script, JRuby, and Groovy will ultimately stand on their own merits, and the use-cases they can carry out on behalf of their users.

In spite of the reactions to this post, I have no interest in diminishing either JRuby or Groovy - I wish them well, and the more they can do for their users, the more power to them.

Indeed, if they were suitable to solve the problems I am trying to solve, I wouldn't have bothered with JavaFX script.

OTOH, pointing out some of the reasons why they may be unsuitable, helps explain the reason for being of JavaFX script - which from my observations is still in question to many readers.

Posted by Christopher Oliver on January 03, 2009 at 08:05 AM PST #

On behalf of the JRuby community, I appreciate your well-wishing. Yes, we have challenges ahead of us, but the Ruby community has grown and prospered with slower implementations than JRuby. So I think we'll remain successful. And I remain excited about the possibilities of JavaFX and I hope to see JavaFX Script promoted as a general-purpose language for the JVM in addition to a language for multimedia applications. The more the merrier, for sure, and JavaFX fills a lot of gaps in the current set of JVM languages.

I would, however, recommend you refrain from future comparisons of JavaFX to languages like Groovy or Ruby. They're entirely different classes of languages suitable for entirely different use cases, and I'd be very surprised if anyone claimed Ruby was fast enough for high-performance graphics work on its own. So your comparison of JavaFX performance to JRuby and Groovy is akin to racing a Ferrari against a 18-wheeler; you're comparing their performance in Ferrari's domain. It doesn't help your case against JavaFX's real competitors.

Posted by Charles Nutter on January 03, 2009 at 09:31 AM PST #

"Indeed, if they were suitable to solve the problems I am trying to solve, I wouldn't have bothered with JavaFX script."

Can you detail what problems you're trying to solve specifically and why you feel JRuby and Groovy are unsuitable?

You talk about graphics rendering... is there a specific reason you don't want to use Java to handle that?

I'm looking at JavaFX and I can't figure out exactly what problem domain it's trying to fit into. As I understand it it's generally targeted at the same domains as Flash/ActionScript, which take a more declarative approach to graphics manipulation which ensures that the performance of the scripting language itself is in no way critical to the graphics rendering.

On the other hand, I see JavaFX is statically typed, which is great from a performance standpoint, but I really wonder how much a statically typed language will appeal to the problem domain that Flash/ActionScript is targeted at.

I see either JRuby or Grovvy as better suited for this problem domain, and personally I would kill for a well-supported Flash-like environment with Ruby scripting.

Posted by Tony Arcieri on January 03, 2009 at 09:58 AM PST #

@Charles Nutter

Thanks, and you're welcome.

However, the comment immediately following yours shows pretty conclusively that more explanation is yet required (sigh)

@Tony Arcieri

Posted by Christopher Oliver on January 03, 2009 at 10:19 AM PST #

@Tony: as far as it has been disclosed on blog posts, the JavaFX rendering pipeline is based on Java code (project SceneGraph) so any JVM language can take advantage of it. Chris, if that continues to be the case, what then makes JavaFX Script better suited for media handling than other existing JVM languages? (yes I'm broadening the scope beyond JRuby/Groovy/Scala)

I must say that JavaFX Script's binding mechanism is refreshing for joining UI elements and data, but it is hardly a unique feature that another language can't pick up, as the Groovy language has demonstrated (it didn't require a grammar change), I'm sure other languages (specially those with meta-programming facilities) can create something similar, yes JRuby can have binding too.

Posted by Andres Almiray on January 03, 2009 at 10:51 AM PST #

Let me see if i understand this correctly. (I have no affiliation to either jruby, fx script or groovy, and don't use them)

Sorry if this comment is longer than your whole post.

1) JRuby and Groovy don't fit your needs for "world class media" because of their performance (because the language features are enough, it seems), so instead of helping them achieve what is needed you go out of your way to create a new language and runtime. Fair enough.

Java doesn't fit your needs either, so you go out of your way to create a new language and runtime that is by, your own admition, \*slower\* ? I'm not sure your boss Mr Framerate would appreciate this very much. He might say that was poor and unacceptable.

If java lacked the features you needed (and are in those other languages you mention), which seem to be binding and some limited type inference, could you have made libs and APIs (like JSR what's his face - beans binding, or any of the 3 or 4 different binding libraries) or, say, used the, albeit very limited, generics type inference, or pushed for further inference or whatever you needed in java, and sooner than java 7 ?

I think it would be possible to have had APIs just because it's already the case, the fx script feature set is compiled into Java source code.

Just like Microsoft invented a new language and runtime to create silverlight, oh wait, they didn't.

2) Are you honestly comparing the work of a team (even if the jfx compiler guys are not that many) payed by a big company, to the open source work people do for free in their spare time (or used to, until pretty recently) when some of them are even your own coworkers ?

Are you comparing the perf of a language no one (maybe not even including you) has the right to publish a benchmark of (btw that scala/fx comparison post is illegal, i don't make the rules) ?

3) If you think c/c++ is fx script's competitor and not microsoft or adobe, why are you publishing benchmarks on actionscript on tamarin, jruby and groovy and not, you guessed it, c/c++ ?

4) When fx script has the same number of users, or more, as rails, ruby, jruby, groovy and grails, or c/c++ in the gaming/CAD world, then you could say it's fair to talk smack. I really look forward to that point.

5) "It's possible to configure the JavaFX script runtime to avoid this - the code is open source - take a look yourself, if you like."

This is where i lose it.

There is nothing, mark my words, \*nothing\* that is open source about the javafx runtime. I know by heart every piece (or close to it) of open source code the fx team has produced (that's sad but what can you do), and there's nothing from the runtime.

One of the smartest moves Sun has made in this hole openjfx endeavor, if not the smartest, is making the building blocks of the javafx runtime usable outside of the said runtime. The fact that they (the open source versions) are pretty much unusable for the reasons i'll expose is on the opposite one of the dumbest.

Scenario and Decora are at the core of the runtime. Scenegraph based Uis/libs have been amongst the forefront of HCI research for a long time (and in game engines, etc), because of the features they provide. (Just providing context for people that might not know about them). Scenario and Decora, as open source projects, are dead. The 0.6 release and last svn activity was a long time ago, no responses on the mailing lists, or the forums. (Chris is pretty much a no-show, and i hope he hasn't left like chet, hans, shannon(?), the other scott, tom, and so on. The fact that he has written one of the only two javafx samples (and apps) that doesn't downright suck reassures me he hasn't but you never know).

And that, even though, they still are being developed in the fx runtime project.

Nevermind the fact that those buggy, outdated, dead versions, are released under the restrictive GPL. On the opposite end, scenario and decora 1.0 that come with the runtime are released under the eqaully as much restrictive javafx license (but for totally opposite reasons).

Then there's the javacss project, which does css styling for swing and fx (and is totally undocumented, for good reasons, there are \*no\* controls to skin - okay actually one, or two). This one is dead as well, and was really short lived, something like two months or less, and has more bugs than scenario (many fixed in 1.0 and more filed in jira). As well here, GPL for the 0.3, and fx license for 1.0.

I won't go into more details about the fx license itself, not now, but just the fact that you have to have the whole javafx runtime as a dependency, and that you can't distribute the whole or any part of it, make even scenario/decora/javacss 1.0 unusable as well.

Sun has changed its mind about them being usable as open source stand alone libraries, even your own employees don't know if this will change again in the future but they do know a lot of changes are going into those core libraries (just for mobile support for instance)

To sum things up: scenario/decora/javacss open source versions are dead, jmc is not open source either, and i believe those round up the ranks of the building blocks. The rest is just code on top.

So, are you actually telling Andres to go look in your open source compiler code, targetting your closed source runtime, in order to avoid executing on the EDT ? That would be bad etiquette, so i guess i might be mistaken.

What open source runtime are you referring to ?

Posted by Rémy Rakic on January 03, 2009 at 05:42 PM PST #


Not sure what you hope to gain by trolling here, tbh - and yes, I'm aware you're a troll when it comes to JavaFX.

Sorry, I won't feed you, however I will answer the concrete question you asked:

The open source runtime referred to is:

Posted by Chris Oliver on January 03, 2009 at 11:59 PM PST #

First, let me point out that I am a minor Groovy contributor, so you may view my opinion as skewed. It's really not, but I'll let you be the judge.

Don't take this as criticism. I took some time to evaluate the possibility of using JavaFX as a scripting language in our server setup, and found it to be severely lacking. But that's not really what it is designed for, is it?

JavaFX, even at the time of the 1.0 release, appears to be aimed squarely at SilverLight and Flash. The lack of support for Java generics and annotations speaks to the fact that if Sun is looking to move JavaFX into server applications, it's something for the future. Right now, it's the front end they are aiming at.

So I think we can agree - JavaFX is not suitable for a back-end scripting language.

Now how about the speed differential shown by this benchmark? Sun has made a commitment to dynamic languages, including both JRuby and Groovy. Both are supported in the latest version of NetBeans, and I think both are here to stay. Both languages have "dynamic" calling mechanisms. That is, they decide how to call a method at runtime rather than at compile time.

Dynamic method calls will probably always be slower than static method calls. Fact of life. There is hope, however. There are (rumored) features in Java 7 that are specifically targeted toward speeding up dynamic languages, specifically around this sort of thing.

I think JavaFX will eventually succeed. I hope it does. It has a lot of good points. It's not a dynamic language, and this limits how expressive it can be. It is also a very simple, targeted language - in some cases maybe oversimplified. Within these limits, it can be as fast as Java (since it is easy to compile JavaFX script right to byte code).

I also think that JRuby will succeed. It lets Ruby programmers get the best of both worlds without leaving one behind.

I also think Groovy will succeed. Groovy is a language that has evolved inside of the Java ecosystem to meet certain hard-to-meet needs. And in that ecosystem, it works better than anything else can for some problems. It is - hands down - the most compatible language with Java. JavaFX includes some design decisions that disturb me a bit when it comes to Java compatibility (using custom/incompatible collections, for example, when java.util.ArrayList would have been fine), plus no annotations, no generics, no side-by-side compile. Groovy is not particularly suited for building applets, but it works great everywhere else. It's supported in every major IDE. It plugs in to Maven seamlessly. It is great for running unit tests. You can use it in a server-side project with other Java classes, and consumers won't even know they are working with compiled Groovy. Okay, I could go on, but that should be enough.

So I see JavaFX as fast but rather limited in scope. Great for applets (small, fast, and doesn't break the applet security model), great for stuff on the client. You know, that is a pretty good niche.

It won't replace Java, JRuby, or Groovy for what those languages are best at. At least not any time soon.

Posted by Jason Smith on January 04, 2009 at 01:12 AM PST #

This is one of the most screwed up chains of comments I've ever had the displeasure to see.

The original post just shows some facts. Those facts are relevant to you or they are not.

But then there are complaints and counter shots and...

People need to stop taking comparisons like these so personally.

That said, saying that "Groovy and JRuby sacrifice an order of magnitude or more performance-wise...[i]n my opinion, that's poor and unacceptable" is unnecessarily incendiary. Why not "for my needs that's unacceptable, but for yours that might be okay"?

Charles Nutter complains that this post is racing a Ferrari against a big rig. It's a good analogy as far as it goes, but it ignores the fact that people may not know a priori that one language implementation is in the league of Ferraris rather than big rigs. Comparisons like these help educate people. And besides, there's nothing inherently wrong with making a speed comparison between Ferarris and big rigs. Nothing prevents others from making an alternative comparison where you try to get a Ferrari to haul a few thousand pounds of cargo up a hill - you see the JRuby and Groovy advocates making the equivalent of that comparison all the time by showing how awkward it is to do any form of metaprogramming in Java.

JavaFX's type system wimpy as compared to Scala and its dynamic metagprogramming facilities underpowered as compared to Groovy and JRuby. Clojure beats them all for syntactic metaprogramming. And none of these languages have the level of tool support that Java has.

Fine, we're all supposed to be professional engineers. Let's use all these facts and others to make rational decisions instead of taking it personally whenever our religion\^h\^h\^h\^h\^h\^h\^h\^h language of choice comes out the lesser in a comparison. At the same time, let's recognize that our needs are not the world's needs. I've done hardware level coding and I've done web apps and I've done language processing and I've done image processing. There is not, nor will there ever likely be, a single language that fits all those niches well.

Posted by James Iry on January 04, 2009 at 01:41 AM PST #

@James Iry

You're right. Thanks and my bad.

Posted by Chris Oliver on January 04, 2009 at 02:11 AM PST #

Chris, i just would like some answers to the questions we've asked for a long time, that's all.

You know, there hasn't been a lot of information coming from you guys about something that ultimately impacts the client side folks a whole lot.

We've asked and waited, i've been nice, friendly, insightful, angry, sad, helpful, cheerfully inquiring, etc so i thought i'd try being antagonizing a little :) If by trolling you mean pointing out the things that are bad and the ones that are good then so be it.

The fact is I've been waiting for the runtime to see what we could do with it for a little over two years, since you first started blogging actually. When the runtime building blocks came out, i've noticed they were really something to watch. The fx runtime has real great potential and will surely become good enough for people to carefully evaluate the options they have when they're doing client side or RIA apps.

Changing one's mind about the libraries, closing the runtime and using such a restrictive license surely has sensible reasons, but the lack of communication about the whole project in general, and that point in particular, makes it that we don't know about them and when we do ask there's no answer.

There's a lot of ignoring people or antagonizing them, as we've seen here.

I think it'll be great when people can use the fx runtime in any jvm language, regardless of its performance or a particular language feature it has. Everyone will benefit from it.

I'd really like to help make that a reality, and the client side java an even better platform. Actions speak louder than words, and i'm doing my part, but no one from the outside can do a whole lot to help with the current restrictions and lack of communication, and it'd be nice to finally know why or when/if the situation will change.

Ultimately, i'd just like some info about those topics.

I'd like OpenJFX to be open.

Posted by Rémy Rakic on January 04, 2009 at 03:18 AM PST #

Chris, since as you acknowledged , JavaFX is mostly targeting high FPS/rich-media "arena", I found an
interesting FPS stress-test example that is implemented both in Flash and Silverlight.

So having a JavaFX version of it I think it will add some real meat here. Please take a look and consider to come with a JavaFX killer implementation of it !

Posted by El Cy on January 04, 2009 at 05:53 AM PST #

Benchmarks are always welcome! It is important to know the times various systems can produce. I suspect that most of us, most of the time have no idea which system can do what in a given period of time. So please no hurt feelings. Linux speed was improved significantly AFTER an "embarrassing" comparison to Windows a few years ago. So hiding slow numbers, slows down progress. I know Groovy is slower in many ways to Java, but I still like and use them both.

That reminds me of fast, cheap and good: choose any two.

Posted by Tom Hite on January 05, 2009 at 01:58 AM PST #

I'm not a huge fan of JavaFX, but I don't get why Chris got such a beating for posting some benchmark numbers?!

Groovy and Ruby are always going to be slower than something that is statically typed. No amount of infrastructure investment in the (complex) dispatch mechanisms of those 2 languages will alter that fact. We've had the Smalltalk people claiming for 20 years of more that dynamic dispatch will one day be faster than static, and it is still nowhere near.

So, what's wrong with highlighting the performance advantages of JavaFX's language model? Sure, it doesn't have a MOP etc, but it doesn't need one for its domain.


Posted by Andrew McVeigh on January 05, 2009 at 08:28 PM PST #

What I find here is just a "healthy" dose of showing off certain advantages of technology in term of performance and feature that might seem offensive to some when a comparison is made. I feel it is a good thing albeit the insensitivitiy that might occur. After all, great nerds and developers are known to be very passionate about their technology to the point that they might not aware of other's feeling. They just simply speak their mind. But that is just the person's personality and I don't think that it is personal at all. In the past great developers like JRuby's Charles Nutter, Grails/Groovy's Graeme rocher have their time debating too over each other language/performance issues, but then I really learn from them when they exchange their point of view countering each other. It's probably the same thing I see here.
It's strange but true that I learn a lot of when people engage in this kind of discussion/disagreement.

Oliver, keep the good work ! JavaFX is surely one outstanding technology alongside Groovy and JRuby that I learning...

Posted by GeekyCoder on January 06, 2009 at 12:45 AM PST #

For the record, my first comment (which sent things downhill) was really a dig on the architecture of JavaFX being the real impediment on performance, and wasn't directed at a particular language. Limiting yourself to one core will do more harm than dynamic dispatch ever could.

It turns out the unthreaded approach does make Mr. Framerate very unhappy.

Note that Flex does just as bad as JavaFX, and it also shares the distinction with JavaFX as being the only other framework to not allow calculations to occur off of the rendering thread. Really, Sun should (and could if they wanted to) fix this in the next major release of JavaFX. It doesn't have to be easy and can be verbose if needed, but they need some way to execute JavaFX Script in parallel to rendering, otherwise JavaFX Script will be just another DSL to draw pretty pictures (a waste of it's potential).

Posted by Danno Ferrin on January 15, 2009 at 11:12 PM PST #

since as you acknowledged , JavaFX is mostly targeting high FPS/rich-media "arena", I found an
interesting FPS stress-test example that is implemented both in Flash and Silverlight.

Posted by توبيكات on May 01, 2009 at 07:49 PM PDT #

thank you

Posted by منتديات on May 01, 2009 at 07:51 PM PDT #

hello yeah but they need some way to execute JavaFX Script in parallel to rendering, otherwise JavaFX Script will be just another DSL to draw pretty pictures

Posted by حرب الخليج on May 01, 2009 at 09:22 PM PDT #

thank you very much.

Posted by çet on May 17, 2009 at 09:18 PM PDT #


Posted by Chat Odaları on May 30, 2009 at 06:38 AM PDT #

Chris has presented a very targeted, specific benchmark. He feels that performance is the most important factor and we should all defer to Mr. Frame Rate.

However, I prefer to look at Mr. License Agreement. I wish I could take advantage of the promises in your benchmarks Mr. Oliver. Unfortunately JavaFX is a botched project because it is too commercially encumbered. My benchmarks show about \*zero\* frames per second for the JavaFX app I never wrote because the runtime remains closed.

Andres, Rémy, and Charles are all working hard to make their efforts open. Perhaps you could be as free with your platform as you are with your performance comparisons?

Posted by Karlin Fox on June 11, 2009 at 11:36 PM PDT #

Posted by matbaa on June 22, 2009 at 02:59 AM PDT #

important and awake! great job bro thanks.

Posted by Egitim on December 11, 2010 at 06:22 AM PST #

Simple and Nice example !

Posted by شات on December 15, 2010 at 03:57 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016