Performance Discussion

[Ozaq]

In this Discussion I would like to talk about the performance of JuPedSim by:

• Collecting interesting and performance relevant scenarios
• Analysing the current performance
• Propose and discuss changes to the software

One note though: JuPedSim does not have high-performance as a primary goal. Keeping the code easy and extensible is more important to our work. Still working with horrible slow code is also not really an option.

[Ozaq]

Proposal - Less frequent route updates

All currently implemented models assume a desired goal as input. This goal is computed by the strategic and tactic decision levels on every iteration of the simulation.

The image below gives a broad overview of the associated cost in v1.2.0 when we use the CollsisionFreeSpeedModel

The numbers look different for SocialForceModel and GeneralisedCentrifugalForceModel but are comparable.

Idea

We speed up the simulation by a factor of 2-4x by simply reducing the number of route updates (when using the above numbers as guide) if we only recompute the target position if we need to do so.

Changes to the target position happen if:

• An agent reaches a stage and is send to the next stage in a journey.
• An agent is in direct steering mode and has a new target set.
• An agent journey is switched
• Then agent is added to the simulation
• The agents position changed so that the agent is now routing around an obstacle differently

Of those changes all except the last are the result of an API call or internal state change, hence we can directly update routing.

The last case is not as straight forward since we only know if the route changes if we compute the shortest path. Here the proposal is to simply accept a delay in rerouting. If we only apply updates every 5/10/20 iterations we might move towards the "wrong" goal for $\Delta{t} * V_0 * 20$ i.e. $0.01s * 1.3\frac{m}{s} * 20 = 0.3m$

This should be a very cheap solution to increase performance by a considerable amount.

[behrisch]

As mentioned in #1421 the last case can at least implicitly be detected / avoided by checking (the lower bound for) the second shortest path. But I think it is also a sensible assumption in general that people do not re-evaluate their route every 10ms. Maybe there is even literature on that? I still like the idea of making it a parameter see #1420.

[chraibi]

it is also a sensible assumption in general that people do not re-evaluate their route every 10ms.

Yes, it seems this way, although I'm not aware of any literature suggesting so.
I think in most situation, this delay is acceptable.

Probably there would be some edgy case where it is not working, but then we will have to see how likely are these edges.

So having some parameter to activate and deactivate "aggressive performance mode" might be an interesting option.