[postgis-devel] Recheck Considered Harmful (or, at least, Slow)

[Paul Ramsey]

I just profiled the newly faster code. memcpy is still the largest
single CPU burner, because we are also de-toasting in the overlap
check and in the spatial function itself.

So, the same savings are available in LWGEOM_overlap, etc, and in the
intersects() function call (for the prepared case, you don't need to
fully detoast the geometry you already have cached) but I'd like to
hear some feedback on this approach. In each of these code paths,
memcpy is still taking 5% of CPU ticks, which is  pretty high.

The only downside I can see is that, for very small objects and
objects without bounding boxes (points) it is hard to avoid detoasting
*twice*, once to see if the bbox is there, and a second time after the
first attempt fails.

P.

On Sun, Oct 12, 2008 at 10:57 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Sick sick sick!
>
> Here's the patch: svn diff -r3090:3091 http://svn.refractions.net/postgis/trunk
>
> Here's the result, on my trusty test case,
>
> Before patch: 8.3s
> After patch: 4.9s
>
> Booyah!
>
> P.
>
> On Sat, Oct 11, 2008 at 5:47 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>> On Sat, Oct 11, 2008 at 5:34 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>>> I guess the deeper question is: what does is this consistent call
>>> (LWGEOM_gist_consistent) meant to achieve, and are we achieving
>>> anything? Can we just return TRUE and be done w/ it?
>>
>> I should read more before I blather. it looks like we are stuck w/ it,
>> but we perhaps with the slice'n'dice detoast we can make it less
>> painful.
>>
>> P.
>>
>