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

[Stefan F. <ste...@we...>]

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


On 05/31/2012 10:50 AM, Mike Bourke wrote:
> This is not a bug per se, but it's something that needs to be mentioned, and
> even improved or resolved before rails can be offered as fully functional to
> the public.
>
> Rails 1.7.x becomes deadly slow towards the end of a game. In today's game,
> I clicked on "no token" for the second-last turn in the last op round and
> had to wait more than five minutes (closer to eight) before the game
> progressed to calculating the revenue for that particular company. 1835 is
> especially bad in this respect because of the potential for a company to
> have multiple diesels, and is almost unplayable as a result.
>
> Note that this problem occurs with ALL actions in an op round. A company
> starts its turn. Click on a hex on the map to indicate where you want to lay
> a tile, wait five-to-ten minutes. The available tiles are offered, click on
> one, wait 5-10 minutes. The tile is then laid, click on it to rotate it
> until correct facing is achieved - wait another 5-10 minutes before the
> first rotation takes effect. Click on "lay tile", wait another 5-10 minutes
> before the game progresses to tokens. Click on a tile to lay a token, wait
> for 5-10 minutes before the option to lay a token in that space is
> displayed. Click on the lay token button, or on the no token button, wait
> another 5-10 minutes before revenue calculations start. Wait up to an hour
> for revenue calculations to be complete (or wait at least 5-10 minutes for a
> value that's close if not equal to the final revenue valuation to be
> achieved) and click Set Revenue, wait 5-10 minutes before being given the
> option of how to distribute that revenue. Click one of the buttons and wait
> another 5-10 minutes for the option to buy trains (if applicable). And so
> on. Clicking on "game" on the game status window menu produces another wait
> of 5-10 minutes before the menu is displayed. Clicking save game produces a
> wait of 5-20 minutes before the save game window appears. Clicking save does
> nothing for another 5-10 minutes.
>
> All this appears to be due to the game consuming 100% available CPU and
> wanting more.
>
> It's understandable that as brown tiles becomes available and the variety
> and length of possible routes increases, it takes longer to determine the
> optimum route. Nevertheless, this all seems excessive, and should have no
> impact on actions like "save game".
>
> I have found that the problem can be reduced (not eliminated) temporarily by
> saving the game, closing rails, and then reopening it, so it appears in part
> to be a problem with the size of the log file (which is always smaller after
> doing so than it was), but this is not the whole issue by any means.
>
> My system is relatively slow by modern standards - only 2.65GHz -
> exacerbating the problem. In combination with the "loading a saved game"
> improvement mentioned a moment ago, I suspect that this is the reason no
> players have noticed / complained about the problem in past testing.
>
> To assess the true scale of the issue, would it be possible to include an
> option to turn logging off in the game setup panel for 1.7.6? I can
> understand why logging in general is both desirable and comprehensive while
> the game is still in a beta-testing mode, but I think this needs further
> investigation. SOMETHING is happening repeatedly in all those CPU cycles
> that bogs the whole game down to a slow crawl.
>
> I also have some thoughts on an alternative top-level process for handling
> revenue calculations but they *might* not yield any improvement (might even
> be worse) and have a wishlist for functionality enhancements, but they are
> unimportant in comparison to this issue.
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 120530-1, 31/05/2012
> Tested on: 31/05/2012 6:50:43 PM
> avast! - copyright (c) 1988-2012 AVAST Software.
> http://www.avast.com
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel