For fast table queries we need to be able to quickly determine the duration of shortcut (in the case of CH) or overlay (in the case of MLD) edge. This is why we save the weight and duration for every CH edge and have two sets of matrices and an additional value on the base graph for MLD.

All this data is only needed for the table plugin. All other plugins use path unpacking to compute the duration/distance value during the query. Removing this precomputed that could reduce the memory we need considerably: The overall memory consumption for CH could be reduced by 25%, for MLD by 20% (approximately, we might run into problems with bit packing for the forward/backward flags).

To make this work we need to change the many to many algorithm in the following way:

1. Don't save the duration in the heap but only the parent node (e.g. here) This means we can remove the special ManyToManyHeap from SearchEngineData which also saves use some memory.
2. Store the parent node in the SearchSpaceWithBuckets here
3. Add a matrix that stores the NodeID of every middle node for every source/target pair
4. Set the middle node whenever we update the weight_table here
5. After we have calculated the full weight row here we run over the row, and unpack the path start, middle and middle, target which yields a list of EdgeBasedNode ids, for which we each extract the segment durations, and sum them up.

The performance crucial step is the last one: We need to unpack a path for every entry in the matrix and calculate the duration value from the segments of the path. These are a lot of operations that would most likely dominate the running time, which would get us something that is closer to running n x m point to point queries.
To get back to our original performance characteristics, we would need to implement a cache that would yield amortized constant time for computing the duration of start, target. While recursively unpacking a path, we can check for each edge if there is an entry in the cache, if not we compute an entry and insert it.

We could implement a thread local cache that is persistent between queries and based on an unordered_map which uses the key start, target, exclude_index. This cache just stores the duration of the path, but we could have multiple caches, for example for storing the distance value to enable #1353. This cache needs to be configurable in size, e.g. max 500 MB to actually yield any memory reduction over the precomputation of all annotations. As a result, we need to implement a replacement strategy like LRU for the cache.