-
Notifications
You must be signed in to change notification settings - Fork 91
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
implement area size heuristic for area:id queries #364
base: master
Are you sure you want to change the base?
Conversation
@@ -287,8 +287,20 @@ void Area_Query_Statement::get_ranges | |||
|
|||
bool Area_Constraint::delivers_data(Resource_Manager& rman) | |||
{ | |||
int counter = 0; |
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.
int counter = 0
in line 311 should probably be removed as well, otherwise line 321 won't return the correct value I guess (variable counter
gets shadowed).
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.
right! forgot to remove that one
it(area_locations_db.flat_begin()); | ||
!(it == area_locations_db.flat_end()); ++it) | ||
{ | ||
if (area->get_submitted_id() == it.object().id.val()) |
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.
Can you check if you could use it.handle() ... instead to get the id (avoids some unneeded object instatiation) - not super urgent.
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.
you mean just changing it to it.handle().object().id.val()
, right? For me that seems to works as well.
It probably should also be changed on line 244…
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 had it.handle().id()
in mind - we have something similar elsewhere but I don't know if this also works in this context without further checking.
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.
ah, yes, that makes more sense 🙈 -> 4d9992d
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 think even the .val() at the end is not needed as id() already returns the right type. Can you maybe test this again?
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.
Then I get the following compile-time error (gcc 6.2):
error: no match for ‘operator==’ (operand types are ‘long long int’ and ‘Area_Skeleton::Id_Type {aka Uint32_Index}’
Uint32_Index has the == operator implemented only for comparing with other Uint32_Index values while Area_Query_Statement (for some reason) stores the id it gets in a 64bit integer.
But I think that calling .val()
here shouldn't be an issue, since the compiler can inline/optimize that away very easily.
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, fine, let's keep val(). I didn't have the source available when commenting and didn't exactly remember when it was necessary.
Cherry-picked the changes to my branch, tested both variants. Memory consumption looks good, there's a somewhat larger runtime in one case, which is due to some unrelated code in area_query.cc. Bottom line: result is still way better than before, though.
|
I had some issues to apply this PR cleanly, although Github claims that everything is fine. I think this a side effect of the most recent |
I think that was simply because the PR was requested against the minor_issues branch. I've changed it to master now and am looking into the conflicts. |
should be resolved now |
fyi: I deployed your patch on the following endpoint: http://dev.overpass-api.de/api_mmd/ |
This one got superseded by dba448f -> this pull request can be closed, there's nothing left to do. |
fixes #359. The implementation feels a bit hacky / inefficient (since we need to iterate twice over all areas now), but I didn't see another way to access the area's
used_indices
property. Any pointers for possible improvements are welcome.