Have in mind that typically running a query passing complex Geometries like Polygons is not advised. Typically one would perform a query using only boxes (so envelopes of Polygons) to perform intersection tests with nodes and values as fast as posible. Then perform intersection tests for Geometries represented by boxes returned by the query and the original Polygon.
Indeed I am doing now exactly this!
Furthermore, currently a copy of geometry is kept inside a predicate object, so potentially big Polygon can be copied. Though I susspect that compiler could optimize it.
Good point.
But indeed if areas of polygons and their envelopes differed greately and many nodes/values could be pruned when Polygon was passed instead of its evelope then the speed might be better. So in other words if polygons was "big" but had small areas, had wierd shapes (thin arms) and/or big/many holes. Do you have such use case or are you passing Polygons into a query from a different reason? E.g. have you measured that this approach is faster?
Good point too. In my case no holes (rings) and probably very few thin arms, if any. Though I will create more test cases do a few performance tests at some point.