Re: [Rails-devel] Revenue calculation performance (was: An ongoing rails issue)

[Mike B. <com...@ip...>]

Saved Game: Will do. Nothing "blocks" the UI but it responds at the same
slow pace as everything else, so the in-effect result is the same. Note that
earlier in the game there is no problem. I have monitored the log file size
as play proceeds and can state that the delays are roughly proportional to
the size increase in the log file, though that may be nothing more than
coincidence. I have also used task manager and can comment that the memory
usage appears quite low; it's the cpu cycles that are maxing out.

Stefan, from your description of how things are supposed to operate, I have
a sudden suspicion that perhaps revenue calculation threads never terminate,
each starting in a new thread parallel to the previous one. By the time you
get to op round 9 or 10, you would then have hundreds of them running
simultaneously.

My idea for route calculation is similar to your caching of old solutions
but several steps further developed. In essence it records all existing
routes as they are created by tile lays and upgrading a tile also updates
those calculations. Right now, the system recalculates route values from
scratch each company's turn in each op round. That entails a lot of
redundant calculation; my idea is an attempt to remove that redundancy by
caching of possible runs. This would probably slow tile laying slightly in
the early/mid-game, but should speed things up in the end game. I'll discuss
that more fully some other time, preferring to deal with that as a separate
issue, possibly even something to consider for version 3 (after version 2 is
up and running, in other words) because it's a fairly fundamental change.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Friday, 1 June 2012 2:45 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Revenue calculation performance (was: An ongoing
rails issue)

Mike:
those are the current options to prevent

* To deactivate revenue calculation as a whole (all phases, complete 
game) choose the GameOption at the start of the game accordingly.

* To avoid revenue calculation during the non-payout step use the 
Configuration Option in Panel "Map" => "Display Routes of active company".

How the interface to the UI it is implemented (at least how it is supposed):

* Revenue Calculation always runs in a separate thread and should never 
block the UI. If it does, it is a bug to be fixed.

* During the Non-Payout steps it only shows the best route as hint (as 
request by John David Galt). You should always be able to select the 
next action and this itself should stop the current calculation and 
restart a new one based on the changed setting.

* During the payout step it should provide intermediate best routes. As 
soon as you enter your own figure or choose distribution it should again 
stop calculation.

Some more comments:
* We had this discussion before (I remember your multiple Diesel 1830 
scenario). Same reply here that running two Diesels on an open map is a 
pretty hard scenario (even for a human player).

* 1835 can be special case as well if the PR has three trains running 
(especially e.g. a 5+5, 6+6, 6+6), as the PR has many tokens so a pretty 
open map for PR too. However it should not be possible to have
a multiple Diesel scenario in 1835.

* Logging should not be an issue (in principle), but one could check 
that too. Logging can be switched by changing the log properties I will 
send you an adjusted one tomorrow for testing.

* Improving the performance after reloading could also point to a java 
garbage collection issue or a problem with available memory on your 
system, however the revenue algorithm does not demand that much memory 
resources, but it could be something else in Rails which limits 
performance here.

Potential improvements to revenue calculation are:
* Dominating train heuristic (already implemented, will be merged into 
rails 2.0):
This avoids calculating the same routes where the two Diesels simply 
swap their routes. Or e.g. that for a 6+6 and 5+5 combination, the 6+6 
will always run the longer route than the 5+5. For two diesels this cuts 
the running time nearly in half, for three trains there can be up to a 
six-fold speed increase.

* Caching old solutions (not yet implemented, will come into rails 2.0 
branch soon):
If the same network is run by identical trains the previous optimal run 
will be taken from cache. This will especially speed up undo/redo activity.

* Design and implement a Maximum-Flow algorithm (not yet started, so 
nothing to expect soon):
Create a different graph which allows to use a maximum flow algorithm to 
calculate the optimal runs (like John Tamplin reportedly did years ago). 
However this will only cover games with standard trains and no dynamic 
bonuses or other complex features (so it should cover 1830, but I am not 
sure about 1835). This would improve speed drastically for those scenarios.

So please do as discussed on the list already: Provide a rails file, 
which allows to test this on other machines and by the developers and 
this could help to figure out the reasons for the problematic 
performance behavior.


Stefan





---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120531-0, 31/05/2012
Tested on: 1/06/2012 4:14:05 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com