The overhead introduced here is non-zero but quite manageable (consistent computing time increase of ~2% for CVRP instances). There is no way around paying the price of using a new metric inside the cost computation anyway if we want this feature. This overhead will probably be swiped away in #1008 anyway.

A longer-term refactoring we could try to improve data locality when computing costs is to store matrices of Eval (embedding travel times and distances for all edges), instead of having separates matrices for travel times and distances whose values are fetched to compute gains at runtime.