Skip to content
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 RTree with RBush #1641

Merged
merged 3 commits into from
Jul 22, 2013
Merged

Replace RTree with RBush #1641

merged 3 commits into from
Jul 22, 2013

Conversation

mourner
Copy link
Contributor

@mourner mourner commented Jul 21, 2013

Replaces the old RTree with RBush, my new high-performance R-Tree implementation.

Everything seems to work smoothly and probably faster than before, but I don't know how to measure the exact performance impact — if you do, I'd be happy to hear the results.

One more thing worth exploring is bulk insertion for the labels code which is not used here because at the moment every insertion is dependent on results of previous ones (tryInsert function). If you can reorganize the code to batch unrelated insertions, we can use bulk insertion and increase performance.

cc @jfirebaugh @tmcw

@@ -43,7 +43,7 @@ describe("iD.Tree", function() {
var node = iD.Node({id: 'n', loc: [0.5, 0.5]});
base.rebase({ 'n': node });
tree.rebase(['n']);
expect(tree.intersects(iD.geo.Extent([0, 0], [1, 1]), g)).to.eql([way, node]);
expect(tree.intersects(iD.geo.Extent([0, 0], [1, 1]), g)).to.eql([node, way]);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had to change the order for the tests to pass, as RTree search doesn't guarantee any particular order of elements. Maybe it would be better to sort on both sides of assertion.

@mourner
Copy link
Contributor Author

mourner commented Jul 21, 2013

Added using bulk insertion for the graph.

@mourner
Copy link
Contributor Author

mourner commented Jul 21, 2013

OK, tried to measure intersects and rebase methods times — intersects times are too small to make a difference (under 1ms each call), but rebase shows an improvement (on the same sample bbox):

// without pull
rebase: 100.698ms
rebase: 18.931ms
rebase: 167.359ms
rebase: 32.507ms

// with pull
rebase: 48.074ms
rebase: 15.812ms
rebase: 21.247ms
rebase: 14.290ms

@@ -1,41 +1,55 @@
iD.Tree = function(graph) {

var rtree = new RTree(),
var rtree = rbush(),
m = 1000 * 1000 * 100,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, what's the reason for multiplying/rounding of coordinates here? Tried removing this and it seems to make no difference.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know. @ansis, can you explain?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... I can't remember. I'm not seeing a difference either. Its likely just a misconception that stuck around.

@mourner thanks for rbush btw. Its awesome to have a more readable and faster rtree.

@mourner
Copy link
Contributor Author

mourner commented Jul 22, 2013

I also noticed that diagonal lines are covered by one big rectangle, and that means that a lot of labels that could be drawn aren't because of false positives. In Kothic JS, we cover diagonal lines by a set of small offset rectangles, and I think you should try the same. Because of bulk insertion, it shouldn't affect performance much.

@jfirebaugh jfirebaugh merged commit 3cedc84 into openstreetmap:master Jul 22, 2013
@jfirebaugh
Copy link
Member

Merged, thanks! I saw nice performance improvements too.

@mourner
Copy link
Contributor Author

mourner commented Jul 23, 2013

Yay :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants