Started by knightly, July 13, 2009, 04:31:43 AM
0 Members and 1 Guest are viewing this topic.
Quote from: jamespetts on July 13, 2009, 08:04:20 AMI suspect that setting up profiling in Linux with Valgrind would be a great deal easier, but I do not use Linux on the computer on which I develop Simutrans-Experimental. Do you have profiling set up at your end for the path searching system?
Quote from: jamespetts on July 13, 2009, 08:04:20 AMI did have a go at profiling once, but I could not for the life of me work out how to get it set up. It required the use of MinGW, which I had previously been unable to set up, and the documentation was very scarce.
Quote from: jamespetts on July 13, 2009, 08:04:20 AMAs to what it might be, the first thing that springs to mind is passenger generation: the step_passagiere() method in Simutrans-Experimental is much changed from that in Simutrans-Standard, and adds a great many additional features necessary for the extra economic depth. It is one of the more computationally demanding elements of the game, so additions to that method can add a substantial amount of overhead.
Quote from: jamespetts on July 13, 2009, 08:04:20 AMThe additional destinations feature in particular means that much of the code (including retrieving paths from where they are stored, which might itself be non-trivial given that the hashtable seems to iterate through a linked list in order to return the value for a key) has to be run up to four times as often (depending on the number of additional destinations generated) as in Simutrans-Standard.
QuoteThere is not anything else in the code like the original path search, however, that is triggered periodically and is very heavy (at least, nothing that I have added for Simutrans-Experimental): the step_passagiere() method runs more or less constantly. If you have the AI enabled, it might be that the AI players are thinking of building something.
QuoteTwo things to check, however: (1) is that sort of reduction present in Simutrans-Standard in any event? Some of Colin's maps are very large, and even Simutrans-Standard might be slow; and (2) do you have other applications running in the background? I find that the fast forward counter speed is often heavily affected by having background applications running at the same time.