Heap Size

PM’d you link, didnt want to upset Decision Games… ;-)

Any luck yet?

Thus spake RonnyUK:

Any luck yet?

I haven’t had a chance to look yet, due to having guests. I’ll try to
look into it this week sometime.


J.

Ok, no worries!
In the mean time, I’ve tried experimenting more:
Changed map images to .png files, made no difference.
Altering my desktop colors to 16 bit seems to help, been a bit erratic, but will sometimes allow the map images to display, albeit extremely slowly. Altering screen resolution to 800x600 makes no difference.
I did notice from task manager that Vassal module can be using as much as 250,000kb and java.exe. over 1.1mb of ram when trying to display the map…

On Apr 27, 2011, at 3:39 PM, RonnyUK wrote:

Ok, no worries!
In the mean time, I’ve tried experimenting more:
Changed map images to .png files, made no difference.

That would not be expected to affect things. It could only affect the
disk space needed.

What matters is the size of the map image in pixels, which is what
needs to be displayed. In general, it will take 4 bytes for each
pixel, so if you take the map dimensions and multiply by for that will
be the minimum memory needed for just the map itself. Other parts of
Vassal will require more.

Altering my desktop colors to 16 bit seems to help, been a bit
erratic,
but will sometimes allow the map images to display, albeit extremely
slowly.

This might help, if the image memory footprint is able to take
advantage of that knowledge. I don’t know if it actually does.

Altering screen resolution to 800x600 makes no difference.

Also not expected to help, since the entire image is created in
memory, even if only part of it is visible at any time.

I did notice from task manager that Vassal module can be using as much
as 250,000kb and java.exe. over 1.1mb of ram when trying to display
the
map…

This would not be unusual for a large map image.
War in the Pacific is a big map.

If you want to experiment with other large map modules, you could take
a look at Case Blue. It is huge.

Thanks Tar, I checked out the map size in pixels, 9680x7652, is over 74,071,000 in total. Multiplyed by 4 = 296,285,000 bytes. Practicaly 3GB? No wonder I’m running out of memory! Is there anyway around this? Apart from the obvious more RAM, that is, as I am running XP… I have copies of the original images used in the module, is there a way to make them take up less pixels?

Thus spake RonnyUK:

Thanks Tar, I checked out the map size in pixels, 9680x7652, is over
74,071,000 in total. Multiplyed by 4 = 296,285,000 bytes. Practicaly
3GB? No wonder I’m running out of memory! Is there anyway around this?
Apart from the obvious more RAM, that is, as I am running XP… I have
copies of the original images used in the module, is there a way to make
them take up less pixels?

Your arithmetic is bad. It should be almost 300MB (282.6MB), not 3GB.


J.

Ahh thanks! Wasnt sure if I had that right!

I just downloaded Case Blue and tried it, (looks good, don’t have the game tho…) and that works ok. I set the preferences to the same in WitP, and it’s now working! It seems that unchecking the “prefer memory mapped files for larger images” is the answer. Map image loads much more quickly, and entire map now displays.

Thanks again for ur help!

Thus spake RonnyUK:

Ahh thanks! Wasnt sure if I had that right!

I just downloaded Case Blue and tried it, (looks good, don’t have the
game tho…) and that works ok. I set the preferences to the same in
WitP, and it’s now working! It seems that unchecking the “prefer memory
mapped files for larger images” is the answer. Map image loads much more
quickly, and entire map now displays.

That setting is one which is helpful for some people, and not for others.
Most likely what’s happening for you is that there’s not enough contiguous
address space left on your machine for doing the memory mapping.


J.

Oh well, we got there in the end, I can get down to playing this monster now!

Thanks for looking into it for me.

Regards

Nick

Guys,

What thus should the initial and maximum heap sizes be?

Thanks

I cant believe after all this time we still cant get a bloody answer. I’m having the same issues with GD 42 runs like a wet week . Thats just loading the map I cant imaging with units on it.

What is the MAX heap you can run please?
What settings IN Preferences can you change to maxmize performance?
Is there a single post I can look at that has these answers as I cannot seem to find it in your search feature. This is the only thread that comes up.
As it appears with 6 cores 16gb or memory and 2 video cards in SLI I cant use this on anything bigger than a one mapper.
I’ll be glad when Oracle kills java for good.

Thus spake hipshot:

I cant believe after all this time we still cant get a bloody answer.
I’m having the same issues with GD 42 runs like a wet week . Thats just
loading the map I cant imaging with units on it.

It’s not a question which has a simple answer. We’ve found from
experience that the same solution doesn’t work for everyone, due to
differences across machines.

What is the MAX heap you can run please?

This depends on how much contiguous address space your machine has at
the moment when you start VASSAL. It’s not a fixed quantity. However,
you say below that you have 16GB RAM, so you must have a 64-bit machine.
If that’s so, then your problem is not too little contiguous address
space.

What settings IN Preferences can you change to maxmize performance?
Is there a single post I can look at that has these answers as I cannot
seem to find it in your search feature. This is the only thread that
comes up.

No, there’s not, for the reason given above. What exactly you need to do
depends on the specifics of your machine.

As it appears with 6 cores 16gb or memory and 2 video cards in SLI I
cant use this on anything bigger than a one mapper.

I can run the GD '42 on my laptop, with the max heap set to 512MB,
wihtout any problems. Since you haven’t stated what’s not working well,
I can’t offer any more advice than that it works for me.

I’ll be glad when Oracle kills java for good.

If Oracle stops supporting Java, OpenJDK will keep going. The decision
isn’t Oracle’s to make. Of more relevance to this point is that VASSAL 4
won’t be Java-based.


J.

Question repost, after a nap.
I’m trying to use GD '42.
the paging or zoom feature will take a long time i.e. 30 seconds+ to one minute to refresh the map, often more.
initial heap is 1024 max 1024. I have bumped it to 4096max 2048 min. Still slow… suggestions?
Other settings:
scroll inc. 100
I’ve tried preferred memory map off and on.
3d pipeline off and on and
high quality scaling is off.

I have x64 6core machine. dual ati 4890s and 16GB memory.
What settings may I tweak to get faster response times.
only chrome running in background.

If the problem is not too little contigous address space what might the issue be?
Thanks guys.

Thus spake hipshot:

Question repost, after a nap.
I’m trying to use GD '42.
the paging or zoom feature will take a long time i.e. 30 seconds+ to one
minute to refresh the map, often more.
initial heap is 1024 max 1024. I have bumped it to 4096max 2048 min.
Still slow… suggestions?
Other settings:
scroll inc. 100
I’ve tried preferred memory map off and on.
3d pipeline off and on and
high quality scaling is off.

I have x64 6core machine. dual ati 4890s and 16GB memory.
What settings may I tweak to get faster response times.
only chrome running in background.

If the problem is not too little contigous address space what might the
issue be?
Thanks guys.

If you’ve done all that, it’s not going to be faster until you’re using
VASSAL 3.2, which isn’t released yet. We’re hoping to release the first
beta soon, however.


J.

I had hoped that when I updated my PC, running the WitP module would be easier, but tbh it’s made no difference!

I now have Windows 7 64bit, and 8GB of RAM, but the module is exactly the same as it was under 3gb RAM and windows XP, it still runs out of memory, regardless of what I do with the heap sizes etc. Unchecking “prefer memory mapped files for larger images” stil works however.

Any idea when the new version will be availalbe yet? Can’t wait!

Regards

Nick

Thus spake RonnyUK:

I had hoped that when I updated my PC, running the WitP module would be
easier, but tbh it’s made no difference!

I now have Windows 7 64bit, and 8GB of RAM, but the module is exactly
the same as it was under 3gb RAM and windows XP, it still runs out of
memory, regardless of what I do with the heap sizes etc. Unchecking
“prefer memory mapped files for larger images” stil works however.

Any idea when the new version will be availalbe yet? Can’t wait!

We’re working out the bugs with 3.2 presently. You’re welcome to follow
the discussion in the developers forum. We’d appreciate having more
people testing builds. (You can find links to current builds there.)


J.

As soon as my developmnet is merged with the trunk I can start testing 3.2 with two modules I am building

I’ll have a look at the developers forum then!

(I have tried installed 3.2, (was a few weeks ago, so may hve been updated since then?) it ran through a process when I first opened the module, (some sort of conversion?) but the module still doesn’t work properly…)

Issue resolved! Turns out it was having too many “area of effects” (command and search areas) open in that particular scenario that was causing it to lock up. Having closed them in another version of the module, it became possible to open the scenario with the latest version, so all is now working perfectly. Thanks to everyone who tried to help.