Battle Calc after 7401 takes dramatically longer

[airwalker1]

My Operating System:

TripleA version:

Map:

Can you describe how to trigger the error? (eg: what sequence of actions will recreate it?)

Do you have the exact error text? Please copy/paste if so

Instead of this error, what should have happened?

Any additional information that may help:

I've tested several versions from 7384 all the way to today's 7554 and have stuck to 7384 as the calc takes forever to use at least in revised in all versions past 7401. I thought it may have been the bot's using different versions but I have tested several as well as others personal host bots to the same effect. I do not know what version the bots were running. Is this not occurring for everyone else?

[RoiEXLab]

@airwalker1
In this case #2540 introduced this Problem,
@ssoloff already proposed a PR to fix this issue: #2617 it should be out fairly soon.

@ssoloff Any Ideas why the PR could have caused such a performance drawback?

[prastle]

I can confirm this but figured it was my bumpkin internet. I also rarely use calc.

[ssoloff]

If anything, #2540 should have improved performance because it no longer makes copies of the game data, which becomes an issue as more and more rounds are played in a game. I suspect #2617 will degrade performance (and that seemed to be my impression when I was testing Greyhawk Wars before and after that change).

However, there was one performance-related bug in #2540 in that it actually ran twice as many simulations as specified, but this should have been offset by the reduced cloning.

@airwalker1 Could you please attach a save game that will demonstrate the performance issues if we run it on different versions? Also, what run count are you using in the Battle Calculator? The default was changed from 200 to 2,000 and then back to 200 recently due to a typo.

[airwalker1]

@ssoloff I did not attach a savegame as it happens 100% of the time. As far as different versions, as I said anything past 7401 has horrible calc times. If you test 7401 vs any new updates you will see the effect. I have used a run count of 10,100,500, and 1000. With 7401 it takes almost no time to run with 1000 simulations, but several seconds after 7401 with a run count as low as 10.

UPDATE: I just ran a test to give you an actual scenario on time. I forgot to mention that I do not see the performance degradation on a local game. When online though with version 7554 I observed the following:

7378 - brand new game, no movements ( revised, bot81-CA, run count 500) - calculated Caucasus with 25 inf, 10 art, 10 tanks, 3 figs, and 1 bomber attacking
Time to calc: less than 1 second.

7554 - exactly same as above
Time to calc: 12 seconds.

[ssoloff]

I forgot to mention that I do not see the performance degradation on a local game.

That's probably the key bit of information that we need. Most of the performance tests for the past month related to the Battle Calculator were done with local games. My impression is that all Battle Calculator code should run locally, so that being in a network game shouldn't matter, but your tests seem to prove otherwise. 😄 I'm going to try to capture network traffic between two nodes while Battle Calculator is running to see exactly what's going on.

@prastle @RoiEXLab So that I can reproduce @airwalker1's test environment as closely as possible, what release is bot81-CA running?

[prastle]

@ssoloff all bots are on your new fix = .7534 As of yesterday. But This issue has been here a long time. Sadly I ignored it because I thought it was me. I have very poor internet at times. It only occurs online it seems.

[prastle]

lol now how do i remove my own thumbs up an down ;) ?

[ssoloff]

Sadly I ignored it because I thought it was me. I have very poor internet at times. It only occurs online it seems.

I remember when you mentioned the online-specific problem when we were debugging #2529. I thought it was unrelated at the time. Apologies. 😞

lol now how do i remove my own thumbs up an down ;) ?

Just click the emoji again. It acts like a toggle.

[prastle]

thanks gl and great job! Theses are minor things compared with the past. We will get there! :)

[ssoloff]

I confirmed I can reproduce this in 1.9.0.0.7554 using @airwalker1's Battle Calculator scenario. For a local game, my run time is ~1 s. For a network game, my run time on the server node is ~2 s, while my run time on the client node is ~15 s. Note that when the run time exceeds 15 s, the Battle Calculator is automatically terminated due to the changes from #2540. In my client node network test, I only end up completing about 50 of the requested 500 runs within the 15 s limit. That is, actually completing 500 runs would take much longer than 15 s.

I re-ran the same tests using 1.9.0.0.7559 now that #2617 has been merged. For a local game, my run time is < 1 s. For a network game, my run time on the server node is < 1 s, while my run time on the client node is < 1 s.

I have an unverified theory as to why #2540 is the root cause of the performance issue as @RoiEXLab suggested and I dismissed above. The #2540 Battle Calculator did not clone the GameData. Thus, on the client node, any change made to the GameData on the client had to be broadcast over the network back to the server. The act of cloning a GameData without its delegates effectively detaches it from the network so that all changes stay local to the node running the Battle Calculator.

TL;DR: It appears reverting #2540 (via #2617) fixed the Battle Calculator performance issue when it is run in a network game. @airwalker1 @prastle Please verify using the latest pre-release (1.9.0.0.7559).

[RoiEXLab]

The #2540 Battle Calculator did not clone the GameData. Thus, on the client node, any change made to the GameData on the client had to be broadcast over the network back to the server. The act of cloning a GameData without its delegates effectively detaches it from the network so that all changes stay local to the node running the Battle Calculator.

Could be the case given that the reference pointed to an object on the bot and the netcode does poor to not existent caching, both of which don't seem that unlikely.
Perhaps this is something we could try to increase the performance of.

[airwalker1]

@ssoloff & @RoiEXLab - looks good! I will use this latest release from now on and report back if any further issues. Thanks for looking into it and resolving so quickly!

[RoiEXLab]

@airwalker1 Always great to hear!