Performance impact of argument order

[dbaston]

When we execute code that leads us to CPL_geos_binop with feature collections A and B, we end up:

• creating a tree of items in B
• iterating over A, and
  • using the tree to find matching items in B
  • if matching items are found, creating a prepared geometry for A[i]
  • calling a GEOS predicate using the prepared geometry

For a point-in-polygon join, we get a big performance boost by preparing our polygon geometries and testing each point against the prepared polygons. But we only end up doing this if our polygons are in argument A and our points are in argument B. If the arguments are reversed, we end up preparing the points and testing them against unprepared polygons, which is much less useful.

Is it worth trying to infer the geometry types of A and B and transparently switching them if it would be beneficial? Or, should documentation inform the user about the performance implications of argument order?

[edzer]

I've been thinking about this too, and believe both are good ideas:

• switch arguments if they are points and polygons
• inform users about what is going on, and performance potential

sgbp object have a t method such that st_intersection(a,b) equals t(st_intersection(b,a)), switching might be easiest in the R code.