Performance issues

Topic: Performance issues (Read 12529 times) previous topic - next topic

Performance issues

May 24, 2009, 10:35:00 am

I downloaded the brand new 3.12 and fired it off. Unfortunately, mere moments after starting I already got feeling that the game got incredibly laggy. What I mean, almost non stop the interface has delays (not fixed) up to almost one second, as if simutrans was non-stop thinking VEEERY hard about something. In previous versions, I was getting this kind of lag only for several seconds after loading the game. Now, it happens constantly.

Oh, and citycars from the old traffic-overpacked save disappered ! The car deletion seems to work great (I hope it's not the thing responsible for slowdown) - the traffic is there but without infinite accumulation.

Re: [3.12] The game seems very laggy

Reply #1 – May 24, 2009, 11:14:38 am

Hmm... can you give me your system specs? What game were you running - the one that you had uploaded with the Polish town names and the Spirals of Doom? If so, I was not getting any slowdowns with that...

Re: [3.12] The game seems very laggy

Reply #2 – May 24, 2009, 12:21:54 pm

My specs:
Lenovo R61i notebook
Intel Core2 Duo CPU T5450 @ 1.66GHz
1 GB Ram
Windows XP Professional SP 2 32-bit

Yes, it was the game with the Spirals, although thanks to the 3.12 patch they were not needed anymore and disposed of (one beautiful day all the cars trapped vanished without a trace).

What I have noticed is that it usually happens when I'm working with lines, adding stops etc. OR when replacing a stop. Seems like it's the pathfinding that is the culprit, because when I do something that doesn't require vehicles to change anything in their paths the game goes smoothly as before.
I suspect the pathfinding fix actually makes it a lot more time-consuming somehow. I never got pathfinding lags like that in any simutrans version (including all standard ones I ever played). True, there was minimal lag for that, but in this case, changing one stop make the game go laggy for several seconds (it doesn't freeze for 10 seconds, just becomes laggy). When I was adding new city lines, it was therefore constantly in "lag mode".

If I get anything more, I'll post it.

Re: [3.12] The game seems very laggy

Reply #3 – May 24, 2009, 12:30:27 pm

Ahh, I see - I suspect that that relates to this set of patches in which the paths are reconstructed every time that you change a stop or schedule. The reason that this was done, I think, was to make sure that paths, etc., were not languishing out of date whenever changes were made. However, it has the result of making things unresponsive during changeovers.

I wonder whether this should be reverted to the previous behaviour? The downside is that it would take up to two game months for the changes to percolate fully, but the upside is that things would be less unresponsive. Any thoughts?

Re: [3.12] The game seems very laggy

Reply #4 – May 24, 2009, 12:39:46 pm

Dantedarkstar :

When you modify lines, add/remove stops, etc., all paths in all halts have to be recalculated (only when paths are requested, i.e. on demand) to accommodate the changes that you have made. You didn't experience the same lag with Simutrans Standard because it does not store all calculated paths, but only search for paths which are needed. This is a fundamental difference in the algorithm used.

What I have done in my pathfinding fix is to bring Simutrans Experimental back to the same level of responsiveness to changes in transport network as that you found in Simutrans Standard. You are right to say that it's the "culprit", but they are necessary. We will see if anything can be done to make the mechanism more efficient. In fact, right now I am trying to optimize the code for rebuilding connexion, and hope I can release it very soon.

Re: [3.12] The game seems very laggy

Reply #5 – May 26, 2009, 11:25:28 am

Dante,

I have found a small but serious bug in my code which should be the cause of lagginess, and I have fixed it now. I have requested James to kindly compile a new version for your testing. I believe this should bring the game back to the same level of responsiveness as in v3.11

Re: [3.12] The game seems very laggy

Reply #6 – May 26, 2009, 06:57:25 pm

Thank's James, I'm also suffering tremendous time lags. At the moment it is taking, sometimes up to 5 Simu-days to recover from an Auto Save and it's getting worse. Sometimes all transport stops, sometimes it's just the Keystrokes and Mouse clicks won't work. Also, even when starting ,the opening screen cannot be opened to full screen until the credits have scrolled off the bottom. This is using 3.12.

My computer is
CPU Dual Core Intel Pentium D 3.6MHz.
NVIDIA GeForce 9500GT with 1GB memory
RAM 4GB

It should be quite sufficient to run Simutrans without any problems, don't you think?

I've copied this from another post (with additions) because it seems more pertinent here.

Re: [3.12] The game seems very laggy

Reply #7 – May 26, 2009, 07:33:38 pm

Colin,

Knightly has identified a bug in some of the code that he wrote that went into 3.12 that causes excessive CPU usage and that we believe may well cause the symptoms that you and others have been experiencing. There is a fix coming up which, we hope, will address the problem: any feedback on the performance of the next version when it comes out will be much appreciated.

Re: [3.12] The game seems very laggy

Reply #8 – May 26, 2009, 09:44:57 pm

Quote from: jamespetts – on May 26, 2009, 07:33:38 pm

Colin,

Knightly has identified a bug in some of the code that he wrote that went into 3.12 that causes excessive CPU usage and that we believe may well cause the symptoms that you and others have been experiencing. There is a fix coming up which, we hope, will address the problem: any feedback on the performance of the next version when it comes out will be much appreciated.

Terrific James. I'll look forward to that. At the moment my game has become virtually unplayable due to the freeze ups.

On another note it looks like reducing the speed bonus has improved my financial return, not by a lot, but much better. I also noticed that the drag and drop is working well with the power lines too.

I've been playing Simutrans since 1985 and it just keeps on keeping on.

Re: [3.12] The game seems very laggy

Reply #9 – May 26, 2009, 09:46:53 pm

1985...? Um, Simutrans was started in 1997. Do you mean 2005?

Re: [3.12] The game seems very laggy

Reply #10 – May 26, 2009, 10:23:56 pm

An insidious imp is telling me he meant in-game year

I also looking forward to the new, better, faster model with lesser running cost... uhm. I mean the new simutrans-exp version.

Re: [3.12] The game seems very laggy

Reply #11 – May 26, 2009, 10:30:22 pm

LOL! Oops ;-) The running cost is not changed in the Simutrans-Experimental version - you can change that in simuconf.tab now (but it will only apply to new games, as with any change to simuconf.tab).

Re: [3.12] The game seems very laggy

Reply #12 – May 26, 2009, 10:50:36 pm

Quote from: jamespetts – on May 26, 2009, 09:46:53 pm

1985...? Um, Simutrans was started in 1997. Do you mean 2005?

Actually I was having an alzheimers moment! it was in fact, I believe (but I wont swear to this) it was late 1995 when I started playing I had just moved from Alice Springs in the NT to a little village called Tumblong in rural NSW in June 1995 and I saw Simutrans on the now defunct PCUser magazine CD. I would have to bow to Hajo on this one though.

Re: [3.12] The game seems very laggy

Reply #13 – May 26, 2009, 10:52:29 pm

Quote from: dantedarkstar – on May 26, 2009, 10:23:56 pm

An insidious imp is telling me he meant in-game year

I also looking forward to the new, better, faster model with lesser running cost.

Me too but they tell me that my heart wouldn't stand it. LOL ( Oh sorry, I missed the Simutrans bit)

Re: [3.12] The game seems very laggy

Reply #14 – May 30, 2009, 03:50:50 pm

The latest version (3.13) should do away with the performance problems of 3.12 - do give it a go and let me know what you think :-)

Re: [3.12] The game seems very laggy

Reply #15 – May 31, 2009, 07:46:33 am

Quote from: jamespetts – on May 30, 2009, 03:50:50 pm

The latest version (3.13) should do away with the performance problems of 3.12 - do give it a go and let me know what you think :-)

Gone past this now James see post elswhere.

Performance issues

Reply #16 – June 01, 2009, 08:42:08 am

Quote from: jamespetts – on May 31, 2009, 11:04:03 am

Nonetheless, at the beginning of every other month, there is a full recalculation of the paths, whether or not the schedules have been changed. This, too, can be time-consuming.

just a sidenote: would it be possible spread the recalculation? I mean, recalculate every connection within one month, but start the calculation of all lines not on the beginning of one month altogether. So that the computational load is spread over one month and not concentrated at one time spot?

I hope this is understandable

Re: [3.12] The game seems very laggy

Reply #17 – June 01, 2009, 12:54:09 pm

Well, I got back from conference and tried 3.14. For me, the lag after each small adjustment to the stops is really bad. Maybe when you still have small network it's okay, but in my save, I have quite developed network, and I can't do anything for about 5 after each small change.

Do we really need precise re-calculation of all paths after each change ? People usually aren't so much up-to date with all the small changes in the transport network. I think recalculation on monthly (or some other time) basis is more convenient (no pauses all the time) and also may model the information lag... sort of.

Maybe the re-calculation can be made a continuous process instead of all-at-once ? I don't know if it's possible for the algorithm you use. I seem to remember it was mentioned Dijkstra algorithm is used. You could do it in small steps, calculating paths from one stop at a time (do I understand correctly that currently whole network is recalculated ?), and doing something like one algorithm step per XXX ticks. The XXX could be a parameter put into the simuconfig, so that it could be adjusted for computer power and even current size of the transport network.

Re: [3.12] The game seems very laggy

Reply #18 – June 01, 2009, 06:14:18 pm

Dante,

thank you very much for your feedback - that is most helpful. I am grateful also for Colin's feedback in another thread on the same issue. I shall have to consider carefully what to do about the performance issues ("lag" is perhaps not the best word, as, in computing, it is usually used in connexion with delays caused by networking - perhaps "unresponsiveness" is more accurate?). I may have asked you for these before, and, if so, I apologies, but can you give me your system specifications (particularly: CPU, RAM and operating system, and anything else that you think might be relevant), and an up-to-date version of the saved game that you use?

One option that I am considering is making immediate updating of the paths optional (as I know that Knightly is very keen on having it in), with perhaps an option in one of the options dialogue boxes to turn it on or off. Any thoughts on that as a possibility would be appreciated, too.

Finally, may I ask: the unresponsiveness that you get: is it constant, random, monthly, bi-monthly, or does it occur just when you add stops or adjust schedules?

Thank you very much for your feedback so far; I am glad that you are enjoying Simutrans-Experimental :-)

Re: Performance issues

Reply #19 – June 01, 2009, 06:35:18 pm

I have moved a post from Dwachs in another thread into this topic relating to performance: it would be helpful if, hereafter, all issues relating to performance in versions > 3.12 could be dealt with in this thread for ease of reference.

To reply to Dwachs' suggestion, I do try to spread the recalculation, but this is not entirely easy, since, as in Simutrans-Standard, goods/p****engers obtain only their next transfer from each stop. So, if at time 1, the path from A to C was via B, and at time 2, the path from B to C was via A, if the paths updated asynchronously, goods might get stuck in an infinite loop between A and B until the paths had fully refreshed. I do try to spread recalculation where possible (for example, by only recalculating a path the first time that it is requested after the old path has been marked stale, not immediately upon it being marked stale), but this does not seem to have much effect as most paths are requested more or less constantly (especially with p****enger networks). If there are any other ideas for making the recalculation of paths more efficient, I should be very interested to know about them!

Re: Performance issues

Reply #20 – June 01, 2009, 08:45:21 pm

The "unresponsiveness" or "lag" I get is every time I change the stops and that is the one that's bothersome, because usually after adjusting the line I want to close the line window and eventually adjust next line, but it's exactly when I have to wait. I seem to get a light bi-monthly lag (I conclude it's bimonthly, because I got absolutely no lag at Aug/Sept change) but it's actually smaller than the one after updating line (only 2-3 seconds).

For my specs:
Lenovo R61i notebook
Intel Core2 Duo CPU T5450 @ 1.66GHz
1 GB Ram
Windows XP Professional SP 2 32-bit
graphic card: integrated Mobile Intel 965 Express Chipset card (don't know if it's relevant, I believe it has sufficient 2d acceleration, only 3d is really lacking, but simutrans doesn't use that)
(I think I really will put it into my sig

)

The savegame in question:
http://simutrans-germany.com/files/upload/Q4_x9_clean.sve

[edit]added graphic card to specs

Re: Performance issues

Reply #21 – June 01, 2009, 08:51:54 pm

Hi James,

Having just read Knightly's post on recalculation I'll wait for your response to his suggestions before commenting further on lagginess. Just for your records, if you haven't read my previous post where I gave my computer stats, here they are again.

CPU: Intel Dual Core 3.6Mhz/
RAM: 4GB.
Graphics Card: NVIDIA GeForce 9500 GT 1024MB

Runs games like HALO2, Far Cry2, Godfather II, Simutrans-Standard. with everything else running. Simutrans-Experimental needs all other processes turned off.

Re: Performance issues

Reply #22 – June 01, 2009, 09:55:13 pm

Dante and Colin,

thank you both very much for the information. I have tried Dante's latest version of the saved game (I am enjoying seeing how you are progressing with it!), and I do not find significant unresponsiveness with that (there is a very small amount when updating a line, but none when adding new lines), however it might be that that setup is slower than mine, which, for reference, is:

Pentium 4 Northwood 2.4@3.0Ghz (FSB overclocked, which also increases the bus speed for the RAM)
2GB of RAM
Windows XP Professional SP 3, 32-bit

However, when testing with a very large and complicated saved game (called "1982" - it is in the Pak128 forum, I think), I do find significant unresponsiveness after updating any line, even after Knightly's latest fixes. I am presently wondering whether or not there is some specific issue confined to updating lines, or whether that unresponsiveness is necessary if the paths are to be kept properly up to date.

Whilst Knightly and I consider those issues, if anyone else has any performance issues to report, I should be most interested in the details (computer specifications and saved games also).

Thank you both for your feedback and information!

Re: Performance issues

Reply #23 – June 02, 2009, 03:28:24 pm

I made good experiences with developing on a rather old system. That means, I had an immediate needs to optimize the code for my own sake, and I noticed very clearly if performance was an issue. Also, if it ran smoothly on my box, it ran smoothly on most other.

It is very hard to optimize a program if you have a very fast PC, since you just don't notice where optimization is needed ... numbers from profiling help, but they aren't as nagging as "This takes 5 seconds each time I click and really annoys me. I'm going to optimize this now."

Re: Performance issues

Reply #24 – June 02, 2009, 09:11:38 pm

I wonder if setting up a virtual machine using software like Virtualbox (my recommendation of the various available options - and it's free) might allow one to slow it down sufficiently. Certainly the amount of RAM could be lessened, which would help match more average machines... and it would use a virtual graphics card, which would also slow things down....

Re: Performance issues

Reply #25 – June 02, 2009, 09:22:00 pm

Wouldn't it be easier to set up profiling than VirtualBox?

Re: Performance issues

Reply #26 – June 02, 2009, 09:24:48 pm

Well, the connection/routing scheme of simutrans has been optimized very much. Incidentally in older versions (until 86.xx) or so there was still the monthly update with all lags. But then the update was done in two steps, first step, recalculate connections and then recalculate goods for every 256th station every step. Thus even extremely big networks are almost unfaacted by any change.

Also the creation of the routing tree and the routing itself was strongly optimized. Thus my reluctance to make any heavy modification to the system in the past. (I could yell now to those old post, that I told before ... ) But on the other hand, people require this, have now a choice.

Concerning profiling: That does not matter much where, as long as it is done.

However, a way out would be a third loop (or even a thread) locking the connections table (i.e. all acttions involving changing a schedule would be postponed until end of recalculation) like the step/sync_step mechanism.

Re: Performance issues

Reply #27 – June 02, 2009, 09:33:19 pm

Prissi,

thank you very much for your input - it is most appreciated. As to threads: that would require quite a major rewrite of the code. Do you recommend adding pre-emptive multithreading (perhaps using the cross-platform Boost libraries, which would have the advantage of improving performance on multi-core/multi-CPU systems), or do you think that it would be better to extend the existing co-operative multi-threading system?

Re: Performance issues

Reply #28 – June 02, 2009, 09:37:29 pm

Multicore CPUs are getting more and more widely used. If you want to benefit from those, real threading is needed.

But be warned, that can be way more tricky than expected. But also, it will be a big step forward, since the cooperative threading of Simutrans only utilizes one CPU core.

Re: Performance issues

Reply #29 – June 02, 2009, 09:42:13 pm

I would not use Boost, but rather Open MP or a cooperative thread (like sync step).

Pseudocode:

interative loop in simworld.cc (very much down)

...
karte_t::step();
haltestelle_t::update_connections();
...

And before a schedule gui is opened or changed etc. do something like this

while( haltestelle_t::update_is_running() ) {
INT_CHECK("...");
}
// now it is save to change a schedule

And
haltestelle_t::update_connections();
{
if(start)
haltestelle_t::update_set_running(true);
// update the next 128 routes/steps/stations ...
...
if(finished)
haltestelle_t::update_set_running(false);
}

Maybe you should do the rerouting also incrementally and only the recalculation in the update loop. Of course the tricky thing is to identyfy all the right places to update. (Usually those are the one just before setting the schedules either in simline or in simconvoi)

Re: Performance issues

Reply #30 – June 02, 2009, 09:44:28 pm

Hajo,

It's the "way more tricky" part that I'm worried about - the priority at the moment for Simutrans-Experimental is ironing out the bugs and stabilising it, so a major rewrite in a difficult area is not feasible at present. Pre-emptive multithreading is probably something that would be good to have in Simutrans-Standard in the long-term (and I've no doubt that Prissi would write threading code far better than I would), so this is probably not something that Simutrans-Experimental should do on its own in any event (especially given the vastly increased difficulties that this would create for importing updates from Simutrans-Standard).

Edit

Prissi,

thank you very much for your thorough suggestions. It might be quite a long time before I am able to get around to looking into this fully (given the feature freeze), but it is extremely useful that I have this information here for reference. I am very grateful. Incidentally, any particular reason why Open MP rather than Boost?

Re: Performance issues

Reply #31 – June 03, 2009, 08:04:18 am

Quote from: jamespetts – on June 02, 2009, 09:44:28 pm

Hajo,

It's the "way more tricky" part that I'm worried about - the priority at the moment for Simutrans-Experimental is ironing out the bugs and stabilising it, so a major rewrite in a difficult area is not feasible at present. Pre-emptive multithreading is probably something that would be good to have in Simutrans-Standard in the long-term.

I see. Actually I thought Simutrans-Experimental might be the ground to test new features, while Simutrans-Standard is conservative and only uses what is known to work well. So I've seen threading rather in Simutrans Experimental.

Maybe in a while, after fixing the currently known bugs.

Re: Performance issues

Reply #32 – June 03, 2009, 08:38:12 pm

Hajo,

thank you for your views :-) My experience of coding is limited, so I am somewhat apprehensive about starting a major new project that requires a high degree of techincal ability - I have no doubt that Prissi's ability to write pre-emptively multi-threaded code is far greater than mine. My emphasis has been more on enhancing and re-balancing the game play and ironing out certain things that I consider to be anomalies (such as having the speed bonus based on maximum rather than average speed) rather than changing the underlying implementation.

That being the case, however, if there was someone with sufficient confidence and time to write and then debug pre-emptive multi-threading code, I could certainly consider it for inclusion. One impediment to that, however, would be problems of keeping Simutrans-Experimental in line with Simutrans-Standard's code base (presently, I regularly merge in changes to the trunk: that might be very difficult if the underlying architecture was changed too much, although should not be too much of a problem with Prissi's suggestion about extending the co-operative model).

One way around this issue would be to move towards a multi-branch, fork and re-merge development strategy for Simutrans-Standard, using Git rather than SVN, where major new features are always individually put together in a separate branch and tested in that branch, and binaries made available periodically, and then selectively re-merged back into the trunk when they are mature. That system could be extended to having separate branches for release builds and nightlies. Quite independently of any Simutrans-Experimental specific issues, I think that that approach has a great deal to recommend it. Indeed, I notice that a number of Simutrans and Simutrans-Experimental developers (Ansgar, Knightly, Gerw, Dwachs and Bernd) are already beginning to adopt this approach.

In summary, I see Simutrans-Experimental as a gameplay fork rather than as a perpetual testbed. It is better to use a multiple fork and merge system to implement test major architectural changes than use a single fork for multiple purposes. In the meantime, I am working to move Simutrans-Experimental towards maturity in its own right (and am extremely grateful to the efforts of all the bug reporters and code contributors on this forum for their invaluable ****istance in that regard), and to release it independently with an automated installer for multiple platforms bundled with one or more Simutrans-Experimental fully compatible paksets.