[http://sourceforge.net/p/ufoai/bugs/3064 Item 3064] imported from sourceforge.net tracker on 2013-01-28 19:58:38

It's because someone added a dozen of func_breakables to the map. And all of them perform a recalc of the routing data.

a) they should be rmoved (the func_breakables)
b) we should finally fix the rerouting times for func_breakables to be able to add more than two of them to a map
===== Comments Ported from Sourceforge =====

====== tlh2000 (2011-10-23 14:56:18) ======

RT_UpdateConnectionColumn is the reason for this slowdown
====== tlh2000 (2011-10-23 15:02:12) ======

nailed it down to RT_TraceOnePassage
====== tlh2000 (2011-10-23 15:14:00) ======

RT_TraceOpening -> CM_EntCompleteBoxTrace -> CM_CompleteBoxTrace -> TR_TileBoxTrace
====== tlh2000 (2011-10-23 16:28:37) ======

it's not the tracing, but the amount of traces - we have to reduce the calls
====== tlh2000 (2011-10-23 16:30:52) ======

G_CompleteRecalcRouting is calling G_RecalcRouting for every model, we should have a way to recalc everything with one call.
====== tlh2000 (2011-10-23 16:41:57) ======

the same is true for multiplayer clients with CL_CompleteRecalcRouting
====== tlh2000 (2011-10-23 16:56:33) ======

assigned this to you aduke, because i could need your input here
====== aduke1 (2011-10-24 20:14:29) ======

I did some profiling too:
Looks like we have 37 func_breakables.
37 calls to Grid_RecalcBoxRouting cause 28720 calls to RT_UpdateConnectionColumn.
/ 2 actorsizes = 14360
/ 8 core directions = 1795
/37 models that's an avarage of 48.5 per model or a 7x7 area.
Sound reasonable so far.

If models are more or less adjacent, there will be some redundant checks of course.
Italy map is 40x40 cells big, so a plain recalcAll wouldn't help us much.

I can think of a dirty-flag method like we use in the recalcRouting after the RMA. That would eliminate the redundant calls, saving an unknown percentage, depending on the placement of the models in relation to each other. Maybe up to 70-80% in special cases.
But it's a bit tricky, so not for 2.4

For the release we should simply reduce actoMaxSize to 1, saving us 50% ;)
We don't have any 2x2 units atm, do we ?
====== tlh2000 (2011-10-25 07:28:45) ======

yes - as we don't use it in 2.4 we should set it to 1 after we branched - because it will also decrease the map sizes and thus the installer size

but for 2.4 we should also remove 90% of the func_breakables (also after branching)

i've updated http://ufoai.ninex.info/wiki/index.php/TODO/2.4
====== aduke1 (2011-10-25 18:20:54) ======

A little update: actorsize 1 will not only save us half of the loops, it will also reduce the area to be rerouted from 7x7 to 5x5. That is, we'll be down to 25% :)

So imho we can leave the func_breakables in for the release (if rerouting time was the only reason).
====== tlh2000 (2011-10-25 19:42:44) ======

it takes ~16 seconds on my system (which is quite fast) - so 25% is still a long time imo
====== aduke1 (2011-10-25 20:18:27) ======

Some 18 sec here (for complete game start) with debug exe, 9 sec for release.
I'm still wondering why it only took 30+ sec with debug and actorsize = 2....
====== tlh2000 (2011-10-26 05:52:33) ======

estate is another candiate (func_door)
====== aduke1 (2011-11-18 21:32:38) ======

The improvement 5 days ago saved some 40% of rerouting time.
Along with the reduction of actorSize to 1 after the branch, we're down to some 10%.
Imho that's fast enough for now :)