1805. Sea of glory. Poor perfomance

Hi
I,m with the lastest vassal version. When I try to load this module it spends 10 minutes to load,consuming 100% CPU. I,m with the maximum heap RAM size. Any suggestion for improving the perfomance? Maybe eliminating the hex grid and the zones?
Thanks

Eliminating the Hex grids and Zones is more likely to break the module as it
is heavily dependent on these for properties

Post generated using Mail2Forum (mail2forum.com)

There is some other issue - I’ll have a look with the Java profiler.

B.

*********** REPLY SEPARATOR ***********

On 2/09/2009 at 4:37 PM Tim McCarron wrote:

[quote]
Eliminating the Hex grids and Zones is more likely to break the module as
it
is heavily dependent on these for properties

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Donegal”:

The problem you’re seeing is due to the interaction between you max
heap size and the very large map image which 1805 uses. I’m working
on a way to mitigate that now.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

I’m looking forward to seeing what you find. I suspect it will be that
most of the time is consumed by image loading.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Our Yourkit license keys have expired, I have emailed for a new set.

B.

*********** REPLY SEPARATOR ***********

On 3/09/2009 at 12:06 AM Joel Uckelman wrote:


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Hi, I’m the designer of the 1805 module. Tim shared some tips with me last week about how to improve module performance, something that’s been a constant problem with 1805. So that I know for future reference, is it the size of the map in terms of its dimensions or its resolution that’s causing the problem?

Brief look shows time spent Image handling to be insignificant. All the time is being spent in SequenceEncoder and SequenceEncoder.Decoder. Have seen this before in modules with many counters with large numbers (ie 100+) of traits on each counter.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Were you timing from the start of module loading to the end? Or from
the start to the point where the side dialog comes up? Or something
else?


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Another issue: Try to save a logfile and you will see it takes several minutes… :confused:

Thus spake “Donegal”:

I’ve also noticed that quitting is extraordinarily slow with the 1805 module.
I believe this has something to do with the comparison which is made to
determine whether the game state is altered (and if so, prompt the user to
save it). Now would be a good time to stop keeping the game state as a giant
string, and instead using a boolean as a flag to inidicate whether anything
has changed since the previous save.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “rfdoane”:

Insofar as the problems are due to the map, it’s the dimensions which are
the problem. The resolution (DPI) specified in the image file is irrelevant,
as that’s completely ignored when the image is loaded.

However, it’s not clear at present that the problem you’re seeing is with
the map. My advice is not to do anything until we determine what exactly
is wrong.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Another tip: Logs generated by the module are 1.3 MB!!! :open_mouth:

Thus spake “Brent Easton”:

I see that SequenceEncoder.Decoder.nextToken() consumes quite a lot of
time. I’m working on optimizing it now.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thanks, will do.

After an afternoon of trying to optimize SequenceEncoder and SequenceEncoder.Decoder, I was able to shave about one second off of the load time of the 1805 standard scenario. Short of looking at the bytecode which the compiler produces,I don’t see any way to make either of these classes faster than they are now, and my guess is that the best possible implementation would not be more than 10% faster than what we have now. (Things I tried which weren’t faster: Using Pattern to do the escaping. Setting StringBuilders to have a larger starting size.)

Therefore, the only way to make the 1805 module load faster is to call SequenceEncoder.append() and SequenceEncoder.Decoder.nextToken() with smaller input. The thing which makes them take so long is that we’re slinging around some gigantic Strings, some of which approach 30k characters in length. If this module is going to load faster, then we need to look into what the source of those huge Strings is, and get rid of them.

What I don’t know at this point is whether this will involve changes in the module, changes in VASSAL, or both. My gut feeling is that it’s just not right to store all of this data, whatever it is, as Strings.

Brent, thoughts?