Am I doing this right?

[Cattlesquat]

Flint1b -- I did the git commands below and couldn't tell any difference, so I think maybe I'm not building correctly or maybe I'm on the wrong branch or something? Brian

git fetch upstream pull/75/head:Try75
git checkout Try75

[uckelman]

Thus spake Cattlesquat:
> Flint1b -- I did the git commands below and couldn't tell any
> difference, so I think maybe I'm not building correctly or maybe I'm on
> the wrong branch or something? Brian
>
> git fetch upstream pull/75/head:Try75
> git checkout Try75

Does 'git log' show the same commit at HEAD for your Try75 branch
as the last commit on the PR on GitHub?

--
J.

[Cattlesquat]

It shows the same commit message as the last commit message in the list ("save property map instead of piece clone as snapshot").
There's a force-push listed in the PR below the commit that isn't shown, but not sure it's supposed to.

[uckelman]

Thus spake Cattlesquat:
> It shows the same commit message as the last commit message in the list
> ("save property map instead of piece clone as snapshot").
> There's a force-push listed in the PR below the commit that isn't shown,
> but not sure it's supposed to.

As that's the only commit in PR 75, if that's HEAD on your Try75 branch
and you're on your Try75 branch, then you've got the PR checked out.

--
J.

[Cattlesquat]

Well dang. All that seems to be true. I wonder why I'm not seeing any perf increase.

[Flint1b]

Hmm.... when I try this first module with current master, add 4-5 of each piece to the map, right click and count, it takes about 2-3 seconds. When I try the same with this PR, it only takes about 1 second. And I get similar relative results with the second module.

[Cattlesquat]

Hmm.... when I try this first module with current master, add 4-5 of each piece to the map, right click and count, it takes about 2-3 seconds. When I try the same with this PR, it only takes about 1 second. And I get similar relative results with the second module.

Oh wow. With current master the test case you describe is "effectively instantaneous" so I see why I'm confused.

Also that gives me a whole new impression of your earlier statement that "Paths of Glory runs like a dog" :O I'm horrified to even think!

[m3tan]

Also that gives me a whole new impression of your earlier statement that "Paths of Glory runs like a dog" :O I'm horrified to even think!

And this is why I choose not to drink from the firehose...

[Cattlesquat]

Naw, ya gotta drink! Who's ever worked as a professional developer and not suddenly found out their thing breaks/lags/etc on some other computer or in some other use case and had to fix something? This is how Vassal gets better!

[Cattlesquat]

But anyway, Flint1b -- now drill down on those modules under YOUR branch and see if you can speed up Global Key Commands themselves!

[Flint1b]

Oh wow. With current master the test case you describe is "effectively instantaneous" so I see why I'm confused.

Also that gives me a whole new impression of your earlier statement that "Paths of Glory runs like a dog" :O I'm horrified to even think!

I think Brent said this with the dog but yea on my computer it's very slow. I am so used to getting a top notch computer from my employers that I don't bother getting a fast and expensive one for myself, as long as I can watch youtube, netflix, play the occasional game and run ms-dos and windows emulators for old games, I'm happy.

That one module I play in PBEM, it does load somewhat faster than Paths of Glory, but I already made it a habit getting a drink while it loads up the opponents log, when I come back it has loaded the counters and almost finished loading the map.

[Flint1b]

For the reference, when I run Paths of Glory 9.8 on Vassal 3.3.2:
- start wizard, select "new game", then "deluxe map something blabla", then it loads for ~33 seconds until I can continue
- then continue (next/finish, whichever works)
- then the Player starts loading and loads for about 2:20min until it finishes loading and the CPU usage goes down

All this time, the CPU usage is often below 80% on one core, and almost no CPU usage on the other 3 cores. Rarely, it goes to 100% on a single core, even more rare is when 2 cores are used up to 100%. And that is not due to I/O, there's hardly any I/O happening during this time.

As a comparison, when I load up Minecraft all 4 CPU cores go up to almost 100% until it's finished loading.

This must be the result of glorious single-thread processing in the AWT event thread, and a model that processes complex things in a recursive manner. I took a look at how these global key thingies work, it's all recursive, I see no way of turning that into parallel processing to make use of all CPU cores.

The doctor suggests slaughtering this thing, taking out whatever parts are useful, and recycling them within a rewrite, in Java, with JavaFX. And including the old code into the new one and offering a "legacy mode" for the modules whose developers are too lazy to adapt modules to new version

[Flint1b]

But anyway, Flint1b -- now drill down on those modules under YOUR branch and see if you can speed up Global Key Commands themselves!

There's also a discussion in that PR now, I'm not sure it will get merged at all, almost wishing I wouldn't have gotten involved with a change that someone else came up with which sounded really good and I just went ahead and implemented it without fully understanding the consequences.

Anyways for my potato of a computer this change makes a huge difference and if it doesn't get in, I will just make a custom version of Vassal for myself and use that instead of the release build. Further discussions about the PR and probably all performance optimizations in general, I give up, whoever wants it merged can take over. I'm going back into "rogue mode", find some useful TODOs on my own and make the necessary changes.

[uckelman]

Thus spake Flint1b:
> For the reference, when I run Paths of Glory 9.8 on Vassal 3.3.2:
> - start wizard, select "new game", then "deluxe map something blabla",
> then it loads for ~33 seconds until I can continue
> - then continue (next/finish, whichever works)
> - then the Player starts loading and loads for about 2:20min until it
> finishes loading and the CPU usage goes down

I had a look in visualvm at why things seemed so slow _after_ the module
loaded.

What I found was 42% of the time was being spent in
BasicModule.encodeSubCommand() while I was doing things like removing
then Neutral Country markers, so I checked there.

private String encodeSubCommand(Command c) {
String s = null;
for (int i = 0; i < commandEncoders.length && s == null; ++i) {
s = commandEncoders[i].encode(c);
}
return s;
}

If the profiling is right, we're spending _ages_ just looping over
these command encoders... Hmm.

--
J.

[uckelman]

Thus spake Joel Uckelman:
> Thus spake Flint1b:
> > For the reference, when I run Paths of Glory 9.8 on Vassal 3.3.2:
> > - start wizard, select "new game", then "deluxe map something blabla",
> > then it loads for ~33 seconds until I can continue
> > - then continue (next/finish, whichever works)
> > - then the Player starts loading and loads for about 2:20min until it
> > finishes loading and the CPU usage goes down
>
> I had a look in visualvm at why things seemed so slow _after_ the module
> loaded.
>
> What I found was 42% of the time was being spent in
> BasicModule.encodeSubCommand() while I was doing things like removing
> then Neutral Country markers, so I checked there.
>
> private String encodeSubCommand(Command c) {
> String s = null;
> for (int i = 0; i < commandEncoders.length && s == null; ++i) {
> s = commandEncoders[i].encode(c);
> }
> return s;
> }
>
> If the profiling is right, we're spending _ages_ just looping over
> these command encoders... Hmm.

And also GlobalProperty.encode() was called about 15k times.

--
J.