Speed up generation of step geometries when there are lots of legs

[danpat]

Issue

While profiling the match plugin, I noticed that performance was about 10x worse when returning step geometries in GeoJSON format compared to returning polyline or polyline6 geometries.

A little bit of digging revealed that we were resizing the step_geometries vector for every leg in the route. For long map-matches, there are lots and lots of legs.

Combine this with the fact that util::json::Value is quite expensive to copy (we should probably look at that separately), it looks like if you do steps=true&geometries=geojson on any match request, the response time is completely dominated by calls to .reserve() at the link above.

This change simply pre-allocates the whole vector before looping over all the legs, avoiding the repeated .reserve() calls and all the copies of the data within the step_geometries vector.

There will be little to no performance change on requests with only 1 leg (i.e. simple /route requests).

For the 1200 coordinate /match request I was testing, this simple change reduces the query time from 7854ms down to 560ms.

Tasklist

• CHANGELOG.md entry (How to write a changelog entry)
• review
• adjust for comments
• cherry pick to release branch

[oxidase]

7.8s -> 560ms is a great improvement!

[TheMarex]

Wow great find! Do you think we can pull this in a bug fix release for 5.16? This would really help with my waypoints benchmarks.

[danpat]

@TheMarex yeah, I think this is an easy candidate for 5.16.2, it's a pretty safe change.

Note that the preconditions for the problem are pretty limited:

• /route with steps=true&geometries=geojson and lots of waypoints creating lots of legs
• /match with steps=true&geometries=geojson - I think steps=true is probably rare here.

The only time that steps=true currently makes sense with /match is if waypoints=0,n is also used, and that causes there to only be a single leg, which also avoids the problem.

So, yeah, worth putting in 5.16.2, and some scenarios will get a big boost, but unfortunately, I don't think this is our most common query parameter combination :-(