Nav 126 re improve performance of raptor

[clukas1]

Improving the performance of the multi day raptor.

This is achieved by creating int based stoptime arrays for all service days based on the trip masks provided by the tripmaskprovider. This stoptime arrays contain additional information to allow jumping between days efficiently.

The array is built up as:

• Index 0: Earliest Stop Time of entire service day
• Index 1: Latest Stop Time of entire service day
• For Each Route: (from Position firstStopTimeIdx of each route)
  • Index 0: Earliest Active Stop Time of Service Day for Route (if any, else NO_TRIP value)
  • Index 1: Latest Active Stop Time of Service Day for Route (if any, else NO_TRIP value)
  • For Each Trip of Route a list of 2 times the length of Stops of the Route Stop Sequence, alternating Arrival/Departure time values.

The StopTimes are created in the new class RaptorCache only known to the Raptor package.

Comparison of Performance:
Before (first Multi Day Raptor implementation only using TripMasks)

After Improvements:

[munterfi]

Heap memory usage for Switzerland:

[munterfi]

After one request:
http://localhost:8080/routing/connections?sourceStopId=Parent8503059&targetStopId=Parent8516161&datetime=2024-07-09T01:10:00

[clukas1]

Explanation of stop times array

[munterfi]

Ufff that was a slightly bigger PR :)

Thanks @clukas1, really good work!

Most of my comments are about naming things, but I also have some functional issues:

• We have a lot of caches now, somehow I feel like we are caching on multiple levels. I would only cache at the outermost level in the StopTimeProvider to have everything in one place.
• TripMask, ServiceDayMask, RaptorTripMaskProvider, maybe combine them with inner classes so it's clear that they belong together and also the hierarchy between them.
• Maybe encapsulate the logic for accessing the stop time array in a StopTimeUtils class?

Overall, the service day masking approach in the Raptor is very nice.

[munterfi]

Thanks @clukas1 for the adjustments!

I found something else, the additional transfers are generated, but not used in the transit service implementation. I am not sure if we can simply remove them from the constructor?

If yes, could you please shortly explain? If no, please fix :)

Except from this, looks good to merge.

[clukas1]

All comments addressed now

[munterfi]

Thanks, @clukas1!

Looks good to merge.