-
Notifications
You must be signed in to change notification settings - Fork 340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve memory allocation for SWAP* insertion ranges #657
Comments
The same kind of same-range-except-begin-or-end situation happens in vroom/src/problems/cvrp/operators/intra_relocate.cpp Lines 39 to 49 in e393809
and in various flavors across the |
The more I think about this the more I'm convinced this would be a big step forward to easily further reduce computing times. Taking a look at how ranges work, it seems we could achieve the desired effect using On the other hand, we don't really need to concat any arbitrary views, simply being able to iterate over an existing vector + a single value before or after. Probably we can come up with some custom structure owning a reference to the vector and the value and offering the required iteration interface. |
@jcoupey do you think this is still relevant and worth pursuing? Copying some values into a On the other hand I did prepare a small class that behaves like a view allowing iteration over a vector with an additional element in front or at back, but am yet to integrate it with the rest of the code. |
@kkarbowiak I don't have a definitive answer here. Probably the impact is less higher than when I filed this ticket due to various changes (e.g. local search operator pruning). Thanks for the ideas, if you have anything that can be tested I'd be happy to do some benchmarking/profiling. |
Understood. Please have a look at #1106. This is a draft of a solution that should work. If it looks promising I will turn it into a proper PR. |
Adjusting the title here as the initial idea proved to be irrelevant based on work in #1106. Options mentioned in #657 (comment) are still worth exploring though. |
In the SWAP* operator, we have to check validity for the addition of a range that consist of a portion of a route with the addition of a single job that is either appended at the front or the back of that range.
When sketching the implementation in #580, I couldn't come up with anything more efficient than just copying the initial range to account for both situations with the added job before and after:
vroom/src/algorithms/local_search/swap_star_utils.h
Lines 101 to 115 in ae413af
This uses
std::copy
for the initial range and apush_back
either before or after copying and is of course very expensive, especially since we have quite a lot of swap choices options to go through. I suspect this is responsible for most of the computing time devoted to this local search operator.Now the initial need is "simply" to pass iterators for the candidate range to the various
is_valid_for_*
validity check functions down the line for tests so it feels wrong to have to copy everything for that purpose. On the other hand, I have not found a more efficient way to describe that range and avoid the copies.Happy to receive any idea or suggestion on that one, maybe the new range library can help here?
The text was updated successfully, but these errors were encountered: