by Jonathan Giles | Jul 7, 2010 | Language Lesson, Performance
Sure, there are plenty of tips discussing how to use sequences in JavaFX, but the one I wanted to cover quickly today is regarding the fact that sequences are immutable. That is, once you create them, their content can’t change.
‘You lie!‘ I hear you all shout, running off to your IDE’s to show me the following fully legal and compiler-friendly code:
[jfx]
var seq = [ 1, 2, 3 ];
insert 4 into seq;
insert 5 into seq;
delete 1 from seq;
println(seq);
[/jfx]
If you run this code, the output will be [ 2, 3, 4, 5 ], as expected. It’s understandable if you think the sequence is being updated in-place – it certainly looks that way from where we’re all standing – except that under the hood it isn’t, and there are performance implications we need to be clear on. To get straight to the point, the insert and delete instructions create a brand new sequence instance, but fortunately they also ensure that the seq variable always refers to the new instance, quietly leaving the old instance to get garbage collected.
Of course, as I just noted, from a developers perspective we can treat seq as a reference to a sequence instance and be oblivious to these ‘behind-the-scenes’ sequence shenanigans. There is nothing wrong with this, but it’s important to know that creating sequences isn’t free, and certainly minimising the amount of sequences we create is a smart idea.
To be slightly more technical, I should note that there are some exceptions to this ‘sequences are immutable’ rule when dealing with non-shared sequences of specific types, but I don’t want to muddy the point of this blog, which is….
Use the expression language features of JavaFX to reduce the number of sequence instances you need to create.
For example, you might have code that looks like the following:
[jfx]
var seq:Integer[];
for (i in [1..MAX]) {
insert i*i into seq;
}
[/jfx]
I hope, with this blog post firmly at the forefront of your mind, you can now see why perhaps this isn’t such a great idea: we’re creating MAX sequence instances, one for each iteration of the for loop – ouch. Importantly, this example isn’t far-fetched and made to prove a point: I just found a very similar example in my code the other day (which I promptly fixed up), and even found a few blog posts on this site and other sites that use this approach. What you actually should do is something like the following:
[jfx]
var seq:Integer[];
seq = for (i in [1..MAX]) {
i*i
}
[/jfx]
In this case rather than create MAX instances of the sequence, we’re creating only one – the result of the for expression. This is considerably more efficient, and can lead to huge performance gains, depending on what you’re doing. In my case it made the difference between my code being usable and being jittery. Obviously in my case this was a very critical for loop, and it may be similar in your use cases also.
I hope that this helps you eek out a little more performance from your apps. Now, go forth and optimise your sequences 🙂
by Richard Bair | Nov 23, 2009 | Language Lesson
We’re intending to write a number of different smaller blog entries focused on describing various features and usages of JavaFX Script. I was asked several times by people this week at Devoxx, why choose JavaFX instead of HTML, Flex, or something else? The two real strong advantages of JavaFX are that 1) you have access to a wealth of Java APIs if you need it, and 2) Developing in JavaFX Script is highly productive.
It is this second point that I hope becomes clear and I hope to convey with this series of Language Lessons. Many times Jasper and I have been holed up writing demos with JavaFX and it is not uncommon for us to just pipe up every so often with “this is just so cool” or “javafx makes some things reaaaaally nice”. I know this sounds like the cheerleader squad coming from the guys who have been part of building this product. Call it pride in craftsmanship. Its honestly how we feel, and hope to convey this to you as we go along.
So with that, here’s the first Language Lesson: Object Creation.
There are actually two different syntaxes for creating objects in JavaFX. One should be used for creating Java objects, and the other for creating JavaFX objects. If you are going to create a Java Object, you will most often want to use the “new” keyword — exactly like you do in Java. You can either use the default no-arg constructor (if the class you are creating has one) or one of the other constructors. For those not familiar with Java, it looks like this:
[jfx]
def obj = new StringBuffer("Hello World");
[/jfx]
The second syntax is what we call the Object Literal syntax, and looks more like object creation in JavaScript than in Java. JavaFX Script supports a different concept for object creation and initialization from Java. In the Java world, you have to call one of a fixed set of (generally) explicitly defined “constructors”, which are essentially special functions that create an object. Each constructor has certain parameters, just like functions.
This usually led to object creation & initialization code that looked like this:
JButton button = new JButton();
button.setText("Cancel");
In JavaFX Script, there are no explicit constructors. Instead, you say what object you want to create and what initial values to give to each variable. If you don’t define an initial value for a variable, then the class will use its own initial value. For example, you might do this in JavaFX Script:
[jfx]
Button {
text: "Cancel"
}
[/jfx]
There are some subtle differences between these two cases for a library author (like me), but it works really exactly the same as far as users of the library (like you) are concerned. The difference is that the traditional Java approach is very procedural (do this, then do that) whereas the FX way is declarative. In such simple examples as this it makes no difference, but as we will soon see as the Language Lessons continue, this declarative style lends itself to some very cool possibilities.
Until next time, have fun coding.
