Menu
▾
▴
Re: [Rails-devel] An ongoing rails issue
|
From: Mike B. <com...@ip...> - 2012-05-31 15:41:22
|
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 |
