gc options for best JFX performance
Jose Martinez
jmartine_1026 at yahoo.com
Mon Jun 4 08:33:46 PDT 2012
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 AnimatedImageView class.
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.
thanks
jose
________________________________
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
Hi Jose,
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 that.
- Michael
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.
>
> thanks
> jose
>
>
> ________________________________
> 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.
>>
>> thanks
>> jose
>>
>>
>> ________________________________
>> 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
>>
>> Hi,
>>
>> 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
>> ----------------------------------------
>> Hello,
>>
>> I have tried the following GC modes but none of them get rid of the noticeable
>> 'stop the world' delays.
>>
>> -XX:+UseParallelGC
>>
>> -XX:-UseParallelOldGC
>>
>> -XX:-UseParNewGC
>>
>> -XX:+UseConcMarkSweepGC
>>
>>
>> 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 in
>> JFX applications?
>>
>> If I cannot find a good set of options I will have to resort to calling
>> System.gc() at strategic intervals.
>>
>> thanks
>> jose
>>
More information about the openjfx-dev
mailing list