traffic:Improve startup performance

[mvglasow]

To address #815, this PR improves performance of the traffic module by deferring location expansion until the location is actually needed, speeding things up when we are starting up with a large number of cached messages or receiving a large feed.

On startup and when receiving a feed, items for the location are generated immediately only if we are currently routing and the rectangle for the location overlaps with the rectangle for the route, as these messages may influence the route.

Otherwise, when a map rectangle is opened on the traffic map, items are generated for locations whose rectangles overlap the queried rectangle.

When the traffic map is queried with a NULL selection (meaning everything should be retrieved), nothing is expanded and items are returned only for previously expanded locations. This is an experimental feature which became necessary since the traffic module occasionally queries its own map (all of which happens with a NULL pointer and would otherwise cause all locations to be expanded). If the current implementation is found to cause trouble, we would need to constrain these operations to a particular rectangle.

When TraFF messages are exported via Dbus, all messages are expanded as part of the operation—so the export can now take quite long when the message store holds a lot of unresolved messages.

This still needs to undergo some tests. Starting up with a large list of messages and dragging the map around works, but routing and export have not been tested yet.

[mvglasow]

Rerouting still has errors when messages are added (removing messages works as before). Freshly calculated routes (after the messages were received) look OK.

[mvglasow]

Rerouting works as of e2d9a74; the error was an incorrect negation. However, freshly calculated messages now seem to have issues. Exports work.

[mvglasow]

Freshly calculated messages work as well as of ee59ece.

[mvglasow]

And the latest batch of updates also fixes the two bugs and limitations:

• Speed limits now should be handled correctly even for items referenced by multiple messages
• When restoring traffic distortions, Navit now compares them to the map (i.e. all active maps in the mapset) and discards all cached data if it does not match current map data

The only open point is that restoring segmented ways currently does not work—segmented ways have to be regenerated from scratch. This would only be an issue with exotic use cases (binfiles from the map download server do not have segmented ways), and would only negate performance benefits introduces by these commits but not impact accuracy of data.

Tested in the lab but not in real-life use cases yet.

[mvglasow]

A brief test on a real device with real traffic messages looked OK. I will likely be making some heavy use of the new features over the course of the next week and then report back.

[mvglasow]

I did a test under real-world conditions today:

• Grabbed all active messages for Poland and Lithuania (some 600, though one-third expires after a few minutes)
• Calculated a route from Munich to Augustów, about all the way across Poland, then shut down Navit
• The next day, opened up Navit and calculated a route in town

Startup and route calculation were still quite slow, which may be in part because restoring some 200–300 locations from cache is still quite time-consuming. It might in fact make sense to defer even restoring of items until a map area containing them is queried.

Also, if a message has cached items but an update for that message is received before the items can be restored, Navit might discard the cached data, negating all performance benefits. I checked, when a message is replaced and the new location matches the old one, the new message gets the entire location structure (which holds the reference to the items in binfile format) and the items, hence no issue here.

[mvglasow]

The latest batch of commits defers restore operations until a rectangle possibly containing the items is queried. That speeds up startup and calculation of short routes; the performance penalty will only strike when calculating a long route in an area with a lot of traffic messages. Probably the best we can get without multithreading. I’ll do some more tests over the course of this week, but I am planning to merge if I don’t encounter any crashes—for a number of use cases this is already a massive performance improvement over what we had before.

[mvglasow]

Real-world performance for a route all across Poland was still disastrous; route calculation with expansion of some 300 items took several minutes.

Iterating over the whole map set once for each item we restore turns out to be quite inefficient. The latest commit takes a different approach: parse everything, then iterate over the map and compare anything with matching IDs and mark items when a match is found. If all items are matched, use the data, else discard everything. In the lab, this has cut route calculation from 60 to 14 seconds (tested with a route from the Latvian-Lithuanian border to Hradec Králové, spanning most of Lithuania and Poland).

[mvglasow]

Ready for merge, except that CodeFactor is preventing me from doing an automatic merge…