rails-devel

[Rails-devel] An ongoing rails issue

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

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

Re: [Rails-devel] An ongoing rails issue

[Erik V. <eri...@xs...>]

Mike,

I'm afraid this is the price you have to pay for having Rails think for you,
rather than doing the thinking yourself.
This refers to finding valid tile and token lays and routes, and calculating
revenue.  I don't believe logging is part of the issue.
AFAIK you can switch off all or part of this thinking, and perhaps more
fine-grained settings are needed.

In the past I have seen a lot of discussion about whether or not route
finding speed can be improved, so I don't expect many quick wins here.
For any improvements you'll be dependent on Stefan, and perhaps others, but
in any case I cannot help you: this subject is not in my skill set.

Erik

> -----Original Message-----
> From: Mike Bourke [mailto:com...@ip...]
> Sent: Thursday, May 31, 2012 10:51 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] An ongoing rails issue
> 
> 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

Re: [Rails-devel] An ongoing rails issue

[Chris S. <chr...@gm...>]

Are other people experiencing the same problem?

--
Chris

Please consider the environment before printing this e-mail.


On Thu, May 31, 2012 at 1:50 AM, Mike Bourke <com...@ip...>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
>

Re: [Rails-devel] An ongoing rails issue

[Phil D. <de...@gm...>]

I personally have never experienced a performance issue in rails, at
worst I've seen it take maybe 30 seconds to calculate a route, and
that was running Diesels on a highly open 1856 map.  Is this
potentially a JVM issue?  Tried a newer version of Java?

Also, could this be an issue of other software/memory utilisation?
2.56 Ghz isn't that old, I'm surprised it's performing that poorly

On 31 May 2012 15:42, Chris Shaffer <chr...@gm...> wrote:
> Are other people experiencing the same problem?
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
>
> On Thu, May 31, 2012 at 1:50 AM, Mike Bourke <com...@ip...>
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [Rails-devel] An ongoing rails issue

[Bill R. <ro...@gm...>]

I have seen rails take several minutes to calculate routes, but it was optimizing multiple diesels for the CGR at the end of an 1856 game.  It's possible to generate a lot of potential paths if there are a couple of parallel lines with many crosses between them.  This was back when route-calulation was done only once per turn, so it was somewhat bearable.

Bill

On 2012-05-31, at 22:55 , Phil Davies wrote:

> I personally have never experienced a performance issue in rails, at
> worst I've seen it take maybe 30 seconds to calculate a route, and
> that was running Diesels on a highly open 1856 map.  Is this
> potentially a JVM issue?  Tried a newer version of Java?
> 
> Also, could this be an issue of other software/memory utilisation?
> 2.56 Ghz isn't that old, I'm surprised it's performing that poorly
> 
> On 31 May 2012 15:42, Chris Shaffer <chr...@gm...> wrote:
>> Are other people experiencing the same problem?
>> 
>> --
>> Chris
>> 
>> Please consider the environment before printing this e-mail.
>> 
>> 
>> 
>> On Thu, May 31, 2012 at 1:50 AM, Mike Bourke <com...@ip...>
>> 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
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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
>> 
> 
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] An ongoing rails issue

[John D. G. <jd...@di...>]

On 2012-05-31 07:42, Chris Shaffer wrote:
> Are other people experiencing the same problem?

I'm not, and I have what I consider quite a slow system (Dell, 2.79GHz, 1GB RAM).
At least, when reading mail I get enough long delays that I frequently hit
repeat-Ctrl-Alt-Del.  The system is otherwise quite nice, but won't take more RAM.

Re: [Rails-devel] An ongoing rails issue

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

I have the latest version of Java as of 8:05 AM this morning, but it sounds
like others have not seen a serious problem in this area. The question
therefore becomes, how typical is my experience? How many others will have
problems of this sort in the future? Is it a problem with WinXP vs later
operating systems? Is it because my hardware can only hold 2Gb of RAM (it's
currently maxed out) while newer computers can handle more?

Erik, Logging is definitely a part of the problem (or reloading a saved game
would not speed up the processing of a turn). But it's unclear how much of a
contribution it is making, which is why I was asking for the temporary
inclusion of a no-logging option.

I can see how "having rails think for me" could be a significant factor in
calculating routes, but don't see how that applies to opening the game save
menu and similar actions.

I propose a test: I will save a late game and then load the saved game. I
will then time exactly how long it takes to perform various actions over the
next operating round. By attaching both saved game and the times to a reply,
I will establish a set of benchmarks. Other people can then load the saved
game and repeat those actions under a variety of conditions. This should
reduce the number of variables involved.

I mention this because I have observed a difference in playing style between
what I and my friends use and that employed by other people - in essence, we
are more cooperative with the tile lays and rail heads and more vicious in
the stock rounds while others are more prone to blocking routes with rail
heads. This difference may be exacerbating or hiding the situation, and
hence would need to be eliminated before meaningful comparisons can be made.
A common saved game would be the easiest way to do so that I can think of.

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

-----Original Message-----
From: Bill Rosgen [mailto:ro...@gm...] 
Sent: Friday, 1 June 2012 1:08 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] An ongoing rails issue

I have seen rails take several minutes to calculate routes, but it was
optimizing multiple diesels for the CGR at the end of an 1856 game.  It's
possible to generate a lot of potential paths if there are a couple of
parallel lines with many crosses between them.  This was back when
route-calulation was done only once per turn, so it was somewhat bearable.

Bill

On 2012-05-31, at 22:55 , Phil Davies wrote:

> I personally have never experienced a performance issue in rails, at
> worst I've seen it take maybe 30 seconds to calculate a route, and
> that was running Diesels on a highly open 1856 map.  Is this
> potentially a JVM issue?  Tried a newer version of Java?
> 
> Also, could this be an issue of other software/memory utilisation?
> 2.56 Ghz isn't that old, I'm surprised it's performing that poorly
> 
> On 31 May 2012 15:42, Chris Shaffer <chr...@gm...> wrote:
>> Are other people experiencing the same problem?
>> 
>> --
>> Chris
>> 
>> Please consider the environment before printing this e-mail.
>> 
>> 
>> 
>> On Thu, May 31, 2012 at 1:50 AM, Mike Bourke
<com...@ip...>
>> 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
>> 
>> 
>> 
>>
----------------------------------------------------------------------------
--
>> 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
>> 
> 
>
----------------------------------------------------------------------------
--
> 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


----------------------------------------------------------------------------
--
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



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

Re: [Rails-devel] An ongoing rails issue

[Phil D. <de...@gm...>]

On 31 May 2012 16:40, Mike Bourke <com...@ip...> wrote:
> 2Gb of RAM (it's
> currently maxed out) while newer computers can handle more?

Yeech, that might do it, I didn't even think it was possible to run XP
on less than 4GB of RAM, I've certainly never attempted it!

Testing user experiences from a common save file on different
configurations seems like a worthwhile exercise to try and get samples
from the user community, I've got at least 4 machines of different
configurations I could test with

Phil

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

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

Re: [Rails-devel] Revenue calculation performance

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

Mike:
your assumption that the calculation threads are not terminated 
correctly seems to be a good first try.

To turn of logging for the revenue calculation:

* If you have a working development setup simply change a line inside
log4j.properties (change from INFO to FATAL).

# log4j.logger.rails.algorithms=INFO
log4j.logger.rails.algorithms=FATAL

* If you use the latest release version:

Copy the attached logging file into the working directory of rails (that 
with the rails jar and rails.sh rails-bat) and start rails with this 
command:

java -Dlog4j.configuration="file:log4j_woa.properties" -jar rails-1.7.5.jar

Stefan

PS: If you can think about a good reuse of previous calculation results 
I would be glad to hear about your suggestions. I do not see how you are 
able to use any previous result if any detail has changed on either 
graph, trains running or special bonuses.

And keep in mind that the main run time stems from the brute-force 
search taking (after the revenue prediction cut-offs), the effort for 
the creation of the graph and all optimizations are neglectable.


On 05/31/2012 08:14 PM, Mike Bourke wrote:
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] Revenue calculation performance

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

Thanks, Stefan. I'll give it a try on Sunday. I've generated an 1856
savegame at the point where things slow down massively - it roughly
coincides with the log file hitting 25Mb in size (25,273K to be precise). As
soon as I get hold of a functioning stopwatch, I'll run some tests and set
some benchmarks.

PS: I think I misidentified the game that is especially bad. I meant 1856.

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): 120531-1, 01/06/2012
Tested on: 2/06/2012 2:45:44 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Revenue calculation performance

[Erik V. <eri...@xs...>]

Nice entry for the wiki!

> To turn of logging for the revenue calculation:
> 
> * If you have a working development setup simply change a line inside
> log4j.properties (change from INFO to FATAL).
> 
> # log4j.logger.rails.algorithms=INFO
> log4j.logger.rails.algorithms=FATAL
> 
> * If you use the latest release version:
> 
> Copy the attached logging file into the working directory of rails (that
with
> the rails jar and rails.sh rails-bat) and start rails with this
> command:
> 
> java -Dlog4j.configuration="file:log4j_woa.properties" -jar
rails-1.7.5.jar
> 
> Stefan