Re: Re: gc options for best JFX performance
goddard at seznam.cz
goddard at seznam.cz
Mon Jun 4 10:44:39 PDT 2012
Wow, few dozens of enemies sounds like a lot at one time.
What's the target resolution?
Regarding the adding / removing nodes, do you use add / remove or toFront / toBack? The latter should be more effective.
BTW would be nice to see the game :)
------------ Původní zpráva ------------
Od: Jose Martinez <jmartine_1026 at yahoo.com>
Předmět: Re: gc options for best JFX performance
Datum: 04.6.2012 17:36:52
That is correct, PathTransitions are being used extensively.
During game play up to 500 enemy units attack in small waves (though this might
go up to 1000 in future rounds). Each unit uses one PathTransition. Once the
small waves begin, memory starts going up. At most there would be a few dozen
units on screen at one time (PathTransitions running).
So with regards to PathTransitions, do they use up memory while running or only
an instantiation? So far I am not concerned with the overall memory footprint
they use up while not running. With all the objects created before game play
beings it comes out to about 100 - 150meg... this is very acceptable. I do not
know where the memory tops off at because the GC kicks in but I would wager it
goes up to 300 - 400 megs (i'll need to verify).
There are a lot of ImageViews being added and removed from children
ObservableList. Though I do not see how but could this be a source of memory
usage? Every unit is animated and I created an AnimatedImageView class that
flips through their List of ImageViews at very fast rates. I will test if there
is memory usage related to adding/removing to ObservableList via this
BTW, I strongly agree performance first memory second. I expect to do profiling
of the code tonight. Will also look into custom PathTransitions as suggested.
Thank you for the feedback, this conversation is sparking ideas that I would
otherwise of not come up with.
From: Michael Heinrichs <michael.heinrichs at oracle.com>
To: Jose Martinez <jmartine_1026 at yahoo.com>
Cc: "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
Sent: Monday, June 4, 2012 4:25 AM
Subject: Re: gc options for best JFX performance
just two short questions so I understand your use case better.
Are you using PathTransition (as your other mail suggests) or Timeline for your
animations? I think Timeline is pretty compact while PathTransition has room for
improvements. :-) Nobody (I know of) used PathTransition extensively so far and
it never became a priority. Maybe your case can change that.
About how many moving objects are we talking? If you have really a lot of
objects, say hundreds, you may be better off writing your own animation routine
based on AnimationTimer. The classes you find in the JavaFX runtime are usually
optimized for fast performance first and memory only second. If memory is your
main concern, a custom implementation can give you significant improvements,
especially if most of your animations are similar and you can take advantage of
On 03.06.2012, at 17:03, Jose Martinez wrote:
> Thanks a lot guys for the good feedback. I'll follow up on it over the next
few days. If anything pops up relating JFX I'll respond.
> From: John Hendrikx <hjohn at xs4all.nl>
> To: openjfx-dev at openjdk.java.net
> Sent: Saturday, June 2, 2012 6:49 PM
> Subject: Re: gc options for best JFX performance
> I really don't think a few KeyFrame and KeyValues is going to have any
> impact -- making them mutable is not going to happen. Just moving the
> mouse over the screen is going to create more objects than that.
> Create some heap dumps, look through them, or profile your application
> and find out where you might be able to optimize a bit -- it's often
> surprising where the real memory/performance issues are coming from.
> On 2/06/2012 16:06, Jose Martinez wrote:
>> Thanks Jiri. Yeah I understand those things. I was naively hoping that
there was some magic concoction of JVM options that works ideally for JFX apps.
>> I try very hard not to create new objects during game play but because the
KeyFrame and KeyValue classes immutable I imagine that those are what are
building up in memory and getting cleaned up by the GC. I create all my
projectiles and enemy units before the round begins. But with each shot fired I
have to create KeyFrames and KeyValues to send the projectile to its
destination. Maybe making those classes non-immutable will help in keeping
memory down. I imagine there might be some complexity to changing a Keyframe
that is attached to a Timeline, or a KayValue that is attached to a KeyFrame,
which is probably why they were designed to be immutable.
>> Also I have to create new Duration objects to keep track of time.
>> From: "goddard at seznam.cz"<goddard at seznam.cz>
>> To: Jose Martinez<jmartine_1026 at yahoo.com>
>> Cc: openjfx mailing list<openjfx-dev at openjdk.java.net>
>> Sent: Saturday, June 2, 2012 4:52 AM
>> Subject: Re: gc options for best JFX performance
>> I believe there're no generic JVM settings for "best performance" Until you
have perf. issues, I'd live with the default.
>> If you want to do perf. tuning, it's application / environment dependent.
Identify your bottleneck (network, i/o, memory, code etc.) and then try specific
settings for that one.
>> If you have big GC pauses, think about how much memory your app uses and if
the heap is not too large, or what's the lifetime of objects in your app and
adjust the generations in the heap accordingly.
>> Regards, Jiri
>> ------------ Původní zpráva ------------
>> Od: Jose Martinez<jmartine_1026 at yahoo.com>
>> Předmět: gc options for best JFX performance
>> Datum: 02.6.2012 07:36:54
>> I have tried the following GC modes but none of them get rid of the
>> 'stop the world' delays.
>> Out of those my favorite so far is UseParNewGC.
>> I also use the following options.
>> --Xms150m -Xmx200m -XX:MaxGCPauseMillis=1
>> Are there other options that you would recommend? Has anyone come up with a
>> concoction of options that works best or a rule of thumb for configuring GC
>> JFX applications?
>> If I cannot find a good set of options I will have to resort to calling
>> System.gc() at strategic intervals.
More information about the openjfx-dev