-
Notifications
You must be signed in to change notification settings - Fork 11
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
Replace the nodesTentativeTime from a map to a vector #262
Replace the nodesTentativeTime from a map to a vector #262
Conversation
We used the node global as a max entry to size the vector. Fetching the temporary data from a map in the calculation loop is too intensive. Using a vector with a constant access is more efficient. We just need to be careful in match the UID of the Nodes
Same benchmark result |
Confirmed that we get the same data as result. |
This is an alternative to #261 |
Benchmark is new vs old? The old is not the same as the old from the other PR, normal? |
@@ -80,7 +80,8 @@ namespace TrRouting | |||
int footpathDistanceMeters; | |||
nodesAccess.clear(); | |||
forwardJourneysSteps.clear(); | |||
nodesTentativeTime.clear(); | |||
nodesTentativeTime.assign(Node::getMaxUid() + 1, MAX_INT); //Assign default values to all indexes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this might explode if we re-read the cache thousands of times in a run, right? But once or twice, it's just wasted space. We're not even sure re-reading the cache works. I think we have an API call, but it was never tested. Maybe we could reset the global ID when we start reading the cache? Anyway, good enough for now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the feature might be broken as you say, and we don't have use case for it at the moment, so we will be good for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is a simpler change than the other one. I think I prefer it
@@ -113,7 +113,7 @@ namespace TrRouting | |||
int minEgressTravelTime; | |||
long long calculationTime; | |||
|
|||
std::unordered_map<Node::uid_t, int> nodesTentativeTime; // arrival time at node | |||
std::vector<int> nodesTentativeTime; // arrival time at node, using the Node::id as index | |||
std::unordered_map<Node::uid_t, int> nodesReverseTentativeTime; // departure time at node |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in the other PR, should you change this too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a comment in the other PR, but it is still pending, so you don't know about it... ;-)
But it's the same kind of map as the one you are changing, is it used anywhere? a little or a lot? Should it receive the same treatment as the nodesTentativeTime and switch to a vector
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it will. It's not are main time sink for the moment, so I wanted to do it it a separate commit at least. I can bundle it in this PR if you want or wait for a following. I kind of wanted to see the impact on the infra with just the first part. But I can do both if you thinks it's better
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, we can try this one in the infra. It's just that those 2 are symetric, so they might be done at the same time, but it would be interesting to benchmark them separately and see if it has any impact at all or none to change it. If you're going to do it next, then I'll approve this one.
New vs old yes. |
@@ -113,7 +113,7 @@ namespace TrRouting | |||
int minEgressTravelTime; | |||
long long calculationTime; | |||
|
|||
std::unordered_map<Node::uid_t, int> nodesTentativeTime; // arrival time at node | |||
std::vector<int> nodesTentativeTime; // arrival time at node, using the Node::id as index | |||
std::unordered_map<Node::uid_t, int> nodesReverseTentativeTime; // departure time at node |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, we can try this one in the infra. It's just that those 2 are symetric, so they might be done at the same time, but it would be interesting to benchmark them separately and see if it has any impact at all or none to change it. If you're going to do it next, then I'll approve this one.
Yep, I'll this that one next. |
We used the node global as a max entry to size the vector.
Fetching the temporary data from a map in the calculation loop is too intensive. Using a vector with a constant access is more efficient. We just need to be careful in match the UID of the Nodes