The ability to use multiple profiles introduced in #450 changed the way we now access cost values. Instead of a single matrix lookup previously, we now have a ponderation with a vehicle-dependent speed factor happening in Vehicle::Cost:
|
Cost cost(Index i, Index j) const { |
|
return static_cast<Cost>( |
|
cost_wrapper.durations_factor * |
|
static_cast<double>((*(cost_wrapper.durations_matrix))[i][j])); |
|
} |
This is a price we have to pay for the sake of a much bigger flexibility in cost evaluation. The downside is that this also means a computing time increase for single-profile instances even with unused vehicle speed_factor (see #450 (comment)).
I've tried to make this as efficient as possible, in particular by providing the Vehicle::Cost implementation in header file to allow the compiler to perform some optimizations in other units. I wonder if there is more to it and if we could improve the structures or the layout to further reduce the increase. I guess this would call for some profiling to get a clearer view of what are the most expensive bits here.
The ability to use multiple profiles introduced in #450 changed the way we now access cost values. Instead of a single matrix lookup previously, we now have a ponderation with a vehicle-dependent speed factor happening in
Vehicle::Cost:vroom/src/structures/vroom/vehicle.h
Lines 67 to 71 in 1e32124
This is a price we have to pay for the sake of a much bigger flexibility in cost evaluation. The downside is that this also means a computing time increase for single-profile instances even with unused vehicle
speed_factor(see #450 (comment)).I've tried to make this as efficient as possible, in particular by providing the
Vehicle::Costimplementation in header file to allow the compiler to perform some optimizations in other units. I wonder if there is more to it and if we could improve the structures or the layout to further reduce the increase. I guess this would call for some profiling to get a clearer view of what are the most expensive bits here.