Remove distances from CH shortcuts #1719
Conversation
| return ((CHEdgeIteratorState) edge).getWeight(); | ||
| } else { | ||
| return weighting.calcWeight(edge, false, EdgeIterator.NO_EDGE); | ||
| } |
There was a problem hiding this comment.
ah this is just a helper method in this test, only for convenience. previously I used weighting.calcWeight but since weighting is a shortest weighting here this is calling getDistance() (which causes an exception for shortcuts). In production code this is a bit different because we normally would use PreparationWeighting (but that does not have the instanceof check...).
Will try (its almost certainly not slower, but I am interested how such a change affects performance as well). |
|
This and this commit seem to have improved the (node-based) CH preparation time by about 10-15% (tried this for Germany only) |
|
Wow, that is a huge number for already highly tuned stuff. Nice. |
No longer store distances for CH shortcuts, they were not really used anyway.
This reduces memory consumption per shortcut by four bytes (now
9*4=36 bytesfor node-based and11*4=44 bytesfor edge-based CH). To retrieve the distance of a shortcut one can useShortcutUnpackerand sum all the distances of the underlying real edges (this is the way we did it for path extraction already).Fixes #1690.