Thus spake Flint1b:
As I already said in another thread, modern Java applications use all
CPU cores to get things done, while Vassal only uses 1 core.
Also, this isn’t true. VASSAL does some very heavyweight things—
nearly all of the image processing—using a thread pool.
–
J.
I haven’t noticed that. When I stopped the time for the “load new scenario” use case, I saw only one core being used in top/ntop. A minute of processing in the background, no GUI changes, only 1 core being used, it must be possible to improve this by using more cores.
Thus spake Flint1b:
I haven’t noticed that. When I stopped the time for the “load new
scenario” use case, I saw only one core being used in top/ntop. A minute
of processing in the background, no GUI changes, only 1 core being used,
it must be possible to improve this by using more cores.
You wouldn’t see any threads loading or manipulating images during that,
as loading a saved game doesn’t involve any painting.
–
J.
Yes, that’s what I’m saying. Must be possible to cut down 1 minute of initializing internal state on one core to 10-20 seconds on 4+ cores.
For anything where user invoked automation is being executed, there is no way you will ever be able to do any parallel processing. It has to run single threaded in a guaranteed order or you will get different results each time it runs. There is no way to tell which Commands in a command stream are dependent on an earlier Command having already been performed.
I am mostly talking about the 1-2 minute startup time. That is the worst.
Otherwise the app runs fine, except for some special commands on some special units.
Thus spake Brent Easton:
I really like the idea of implementing a top-hat trait that we place on
top of each GamePiece when it is created so that every single unit has
one.
I’m in the middle of trying this.
–
J.
I’ve added PieceWrapper, a Decorator subclass that’s intended to be a top-level trait. I’m not getting this to work—I see lots of exceptions when loading any module. What I’m I doing wrong?
github.com/uckelman/vassal/tree … ccess_work
(Everything up to 548d06b is refactoring. It’s only from that commit onward that I’ve added PieceWrapper.)
It could be interesting to run this CPU profiling on the module I made:
http://www.vassalengine.org/wiki/Module:Verdun:_A_Generation_Lost
There is a horrible lag when you move units connected to the German and French Artillery Tables. These tables were made to automate the calculation of range and firepower of artillery on a specific target. I managed to implement this without a custom class but used many Java expressions in the traits. I suppose these expressions have to be interpreted X numer of times and the whole is therefore very slow.
I have switched to playing my current PBEM games with the current master. With the PieceCloner improvement merged playing became much more fun, I am not going back again.