The International Simutrans Forum

I suspect this is not a pak64-specific issue...

Meanwhile, have you compared the performance of the GDI executable vs. SDL?

Can you post your savegame?

There was a brief period of reduced responsiveness immediately after loading, but soon afterwards the game ran smoothly. When I tried to add a halt or adjust certain convoy's schedule, responsiveness was reduced again shortly afterwards for quite some time.

So, probably the reduced responsiveness is caused by the re-routing of all existing ware packets in one single world step after set_schedule_counter() is triggered by actions like halt construction/deletion or schedule changes.

I have just tried Colin's save game.

There was a brief period of reduced responsiveness immediately after loading, but soon afterwards the game ran smoothly. When I tried to add a halt or adjust certain convoy's schedule, responsiveness was reduced again shortly afterwards for quite some time.

I've noticed the same, while trying Colin's game. So it's the rerouting of goods, which makes the game laggy...

Reduced by quite a lot and when building a game, because one is continually adding halts or new schedules, it happens with repeated monotony. Every few game days actually, and not counting Auto Save which I've extended to every 3 months. Brave little Aussie fellow that I am. ;D ;D ;D

Gerw, is it possible to spread the load of re-routing ware packets across a few steps?

It's currently spread across 32 steps, see spieler_t::step. But maybe this number should depend on the time, the rerouting needs.

Thanks a lot for pointing out. :) It is quite incredible that after spreading re-routing across 32 steps, the game is still so unresponsive.

I could set the station coverage back to 2 but surely that would lead to an increase in Trams/Tram lines/Stations, creating even more route finding?

It makes a loss of over 41 thousand (not in travel costs) when the p****engers leave. It returns home with over 300 p****engers and makes a profit of over 22k when the p****engers leave. Have I got a setting in wrong in the config.tab or is this another bug?

As I wrote, my suggestions (if they matter at all) will not help (much) in the case of the p****enger/mail network.
Directly, it will only increase routing calculation effort to a smaller extent, because of the larger number of stations ("hops"). But usually, you will have more different lines, more interconnection points and more transfers, and that makes a big difference.

Do you mean that if I make multiple smaller Tram networks in my cities instead of one large network it would improve the flow of the game?

As your savegame doesn't contain an extremely large network, there may be a performance bug. Additionally, Z9999 may be right when he said that ST has become "too heavy".

Regarding the obscure revenue: It's unrelated to the program performance problems, so could you please open a new topic for that, also providing the savegame with the train? After that, I will move my own replies and any remaining related text there.

The station coverage is not important.

The problem in your savegame are not the size of the map but the shear amount of waiting persons. You have several stations with more than 300000 people waiting. Updating such a monster will of course take some time.

I will look into the code to make it smoother, although no promises ...

Hi Colin :)

According to the source code update history, Prissi's changes for speeding up re-routing have already been incorporated. So, does it improve the responsiveness of your game?

Knightly

No, if anything it's getting worse. I'm sorry to say.

void spieler_t::step()
{
   if(  halt_list.get_count()>0  ) {
 
      uint32 it = halt_iterator_start;
      slist_iterator_tpl <halthandle_t> iter( halt_list );
      while(  it>0  &&  iter.next()  ) {
         it--;
      }
      if(  it>0  ) {
         halt_iterator_start = 0;
      }
      else {
         uint32 units_handled = 0;
         while(  units_handled<8192  ) {
            if(  !iter.next()  ) {
               halt_iterator_start = 0;
               break;
            }
            halt_iterator_start ++;
            // iterator until 8192 p****engers were handled
            units_handled += iter.get_current()->sum_all_waiting_goods();
            iter.get_current()->step();
         }
         INT_CHECK("simplay 156");
      }
   }
}

I strongly suspect that you fell victim to a display bug: the sum of p****engers of the packages displayed is never 300k, not even close. I guess lots of destinations with letter >B are missing.

Doing in one step caused the lag that we are trying to get rid of

Not sure, what "BSF"

but rerouting all goods of one of the large stations took more than 100ms

For a given source vertex (node) in the graph, the algorithm finds the path with lowest cost (i.e. the shortest path) between that vertex and every other vertex. It can also be used for finding costs of shortest paths from a single vertex to a single destination vertex by stopping the algorithm once the shortest path to the destination vertex has been determined.

Thanks Gwer, and many thanks to Knightly who has tried his hardest to guide this addle brained gamer through my trials and tribulations.

Although 500 steps mean two minutes.

         if(waren[last_catg_index]  &&  waren[last_catg_index]->get_count()>0) {

            vector_tpl<ware_t> * warray = waren[last_catg_index];
            while(  last_ware_index<warray->get_count()  ) {

               if(  suche_route( (*warray)[last_ware_index], NULL, false )==NO_ROUTE  ) {
                  // remove invalid destinations
                  warray->remove_at(last_ware_index);
               }
               else {
                  last_ware_index++;
               }
               // break after a certain number of reroute actions
               if(  --units_remaining==0  ) {
                  return false;
               }
            }
            // now we are finisched with this array
            // => reset last_ware_index for the next categorie
         }

I did some testing with this and yoshis game and I think I reasonable balanced it.

As for Gerw's suggestion to combine multiple searches for each individual packet into a single search, I think he is right that such combined search can reduce search time significantly, by eliminating the need to rebuild search trees from scratch for each individual packet. However, I think search time cannot be reduced to such a short time as entailed by the single longest individual search, because each examined halt needs to be compared against a list of outstanding ware packets' destination halts to see if there is a match. With a large game like Colin's, some halts may have over 900 pax packets, so even a combined search have to take quite some time to finish, still causing unresponsiveness problem.

Can anyone tell me why my uploads always have a Red 'File Delete' where the uploaders name usually goes?

If you sort the destinations of the 900 packets, you can use binary search and you will need at most log(900) = 10 comparisons each step (Maybe a hash table is even better?). Further, you can kick out the packets, for which the route is already found. Imho, it takes maybe the time of routing 5 packets (with long route).

I see. Look forward to your patch then :)

Usually the RESCHEDULING takes more time, since one has to loop over a lot of convois and lines.

Therefore building a search tree most likely will take longer than the actual rescheduling; also most stations have also in colins game very few people waiting.

also most stations have also in colins game very few people waiting.

   /* Need to clean up?
    * Otherwise we just incease the mark => less time for cleanups
    */
   if(  current_mark == 0xFFFFFFFFu  ) {
      slist_iterator_tpl<halthandle_t > halt_iter (alle_haltestellen);
      while(  halt_iter.next()  ) {
         halt_iter.get_current()->marke = 0;
      }
      current_mark = 0;
   }

Most interesting thing is London_C.sve with max_hops 8000.
It's really the same as max_hops 2000.

regbombay1's London_C.sve (4297 convois, 8577 halts)
max_hops 8000
 standard 37259 ms
 Knightly 4548 ms
max_hops 2000
 standard 5517 ms
 Knightly 4534 ms

Only the service counter is not included, since to me it seems like the warenziel-list does essentially the same.

I.e. only adding when reachable_halt->get_warenziele[ware_catg_index].get_count() > 1 ? Since hat gehalten just adds to warenziele anyway.

But your patch, if I have two convois with the same schedule, then it will be too larger than 1 ... Or did I mistake it completely? But it would be still an improvement for any case without this.

reachable_halt->get_warenziele[ware_catg_index].get_count() > 1

But your patch, if I have two convois with the same schedule, then it will be too larger than 1 ...

Additional information. The percentage of transported p****engers.

regbombay1's London_C.sve (4297 convois, 8577 halts)
max_hops 2000
 standard 9%
 Knightly 83%

Can I use your patch for any fork version of simutrans, if this was denied ?

It will be incorporated. I will probably just get this a more descriptive name (like number_of_non_unique_schedules or so ... )

The counter of warenziele is large after addition.

I did profiling, but the differences are small; moreover, most improvement seems from less calls to halthandle_t::is_bound() and halthandle_t(). But as z9999 said, I think most people actually finding a route is more important.

This will certainly perform different on different processors, the longer the pipeline, the better.

I am quite torn on this; even in your old patch you used an unchecked array, which was marginally ok, since it was only accessed with an predefined counter.

However, for a large project like simutrans, I would like to keep objects together. The mark of a station belongs imho to the station.

People tend to forget, what things belong together. Keeping things together with their data was imho the main idea of OOP. Maybe I have become to fundamentalistic in my views. But I am certainly open to challenge my optionions by arguments.

Keeping things together with their data was imho the main idea of OOP. Maybe I have become to fundamentalistic in my views. But I am certainly open to challenge my optionions by arguments.

I agree that things that go together should be grouped together in their respective cl****es. And I agree with the doctrines of OOP too. But sometimes we tend to ****ume that certain variables should belong to a certain cl**** of objects; but if we think deeper, there may be no necessary connection between them.