graphhopper: point_hint too slow for certain cases

The newly introduced number handling caused an issue. If I just remove

try {
    if (Integer.parseInt(rewrite) > 0)
        isNumber = true;
} catch (NumberFormatException ex) {
}

routing requests like /maps/?point=1.346528%2C103.753174&point=1.348105%2C103.747788&point_hint=&point_hint=Singapore are already much faster. Will see what else can be done.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 18 (16 by maintainers)

Most upvoted comments

You won’t be disappointed, better than Slack IMHO.

Sorry, I usually don’t spam other repos with my personal opinion. And you know I love your work here. I do feel generally though that several discussions in issues/PRs in GH repo is often more an internal discussion, better suited for your forum (still public at least) or chat. Putting only the milestone comments to GH would make it more understandable for other people too, instead of having to go through 50+ comments (you gotta admit, not that uncommon). Anyways, just wanted to mention it:)

nilsnolde on Sep 9, 2019

A simple LinkedHashMap (LRU) reduces this now to only +20%

Could you profile the execution with jvisualvm? Would be nice to see where we’re loosing performance exactly.

Sure. JaroWinkler.similarity is one and the other is still prepareName

but use the regular String similarity metrics without any Unicode normalization

What do you mean here?

~~@otbutz let us go to https://discuss.graphhopper.com/t/improve-speed-of-point-hint/4728~~

(btw: I really dislike that github sends one email per issue entry. Does not make sense if there are multiple per minute)

karussell on Sep 9, 2019

It seems to be the only test case which fails and I wouldn’t have expected it to return i28north to be honest. Blindly adding the i from I- could be dangerous.

otbutz on Sep 9, 2019