There’s been a series of posts at Consimworld for the past two days which
has me stumped. Several people are finding 3.1.0-beta5 to be dramatically
slower than 3.1.0-beta4. The conversation starts with this post:
Now, everyone reporting this appears to be a Windows user, but they seem
not to have much else in common. One has a pretty anemic machine, one has
a very beefy machine. This isn’t happening for everyone, though, and it’s
definitely not happening for me. For me, beta5 is somewhat faster at
zooming and painting tiles than beta4, on both my Linux development box
and my wife’s Windows XP box (which, incidentally, is at least
superficially similar to the machine of Jim, one of the guys having this
problem).
I suppose that nobody reading here has had this problem, or there’d have
been posts about it already, so… Any ideas about how to proceed?
I can say unequivocally that I found beta 4 (and previous before somewhere around 4360-70-something) to be dog slow on my Strategos module, and beta 5 to be perfectly playable.
Perhaps different types of modules. Strategos has very involved graphics per piece with DP’s and layers and all kinds of crud, and the need to do a lot of multi-selecting to boot, but over the whole map, which is downright miniscule, there are not very many pieces.
Perhaps a module with a ton of pieces or a very large map might be a different story?
But… I have to say that playing GMT/CoM and GMT/AW/CR on Beta5 for a couple PBEM turns now is not noticeably any problem at all.
But I guess me saying that is not really what you are looking for - apparently someone is having trouble so what you really need is someone experiencing the same thing to let you know what it is exactly.
Just to be sure I tried it on my pirate homebrew module for SPI Conquerors which has two very inefficient large full size maps that I never bothered to work down to size, plus a gazillion charts and tables graphics, all scanned jpegs still sitting at about 150dpi.
62 MegaBytes, all in the jpeg maps and charts and tables with no counters yet, versus only 355 kiloBytes for Strategos which is nearly complete.
It (SPI Conquerors) actually loads faster under beta5 than it did under beta4. About 10 sec versus maybe 15-20 sec. I do notice, I think, that the little circley doo-dads telling me it is in process do not come up in beta5 but did in beta4. So for those first 10 seconds I thought crud maybe it is not loading. EDIT - actually it is just that on that module I think I set the cell size to cover essentially a whole map, so the cells are real big - it should take forver to load up as I did almost nothing right in the module design except git 'er done (and even that only 90%).
I do not have prefer memory-mapped images set in my player preferences for playing either module.
256 / 512 MB set for JVM init/max heap.
Java… well I have the latest 1.6.10 or whatever from Sun but iirc that does not mean that is the version Vassal is actually using does it, there could be an older version of Java installed on my machine that Vassal is trying to use - is there a way to tell?
Q6600 @ 2.4GHz with 3GB RAM, 32-bit windoze Vista (Home Ultimate I believe)
So again no help for you but at least it not just the map file size that is causing whatever the problem is. I’m sorry, I am probably just adding noise, I will shut up and let someone else try it.
I just tested beta 5 on my F&E module. It’s hard to tell, as it is already a little slow on my system, but I think performance is down for me. But, if so, it is subtle.
uckelman, you should already have a copy of the module to play with, you might want to try it out, as it’s one of the better stress tests I know of for Vassal.
Note that this is all in game actions. The load times and such are about the same as they’ve been since beta-1. Nor am I having the excessive map loading times that are being reported (I suspect that is a more extreme version of what I see), where dragging counters from the pallet, moving stacks of counters, and so on is slow. The image for what I’m dragging will ‘stutter’ and lag a couple seconds behind, and I think this is more pronounced now than before.
No, wait, I did have the AVL map take a surprisingly long time to load once recently. But just once. I have no idea why that one load would have been any different.
That’s what I would have expected. What you’re seeing is the combination
of the scaling algorigthm being faster at handling fully-opaque images
in beta5 than in beta4, and no overhead in beta5 from drawing the spinners.
Drawing the spinners was stealing time from the thread doing the scaling,
and I think the fade-in is a nicer effect anyway.
Right, the load time is the same all the way from beta-1 to now.
I have been having problems with actions inside the module being a bit slow, and I’m trying to judge whether or not it’s slower now than it has been… and I’m not quite certain.
Assuming that the current problem is unrelated (and given the symptoms reported, I’m now thinking that it probably is), I’m hoping that optimizing the performance some can be looked into for 3.2.
Back to the current issue, can you get some of them to have Task Manager up while they load Vassal and see if the system thinks it is doing anything at the point it has trouble? (Is Vassal or Java spiking on CPU time, etc…)
I recommended to one person that he should lower his max heap, because
he had it set to the amount of RAM he has, which should guarantee some
swapping will happen once VASSAL’s cache fills up. But that’s a general
recommendation for any version—don’t set your max heap so high that
you cause your OS to thrash. He hadn’t changed his heap settings from
beta4 to beta5, so I don’t see that it’s a heap issue.