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

Paul Ramsey pramsey at cleverelephant.ca
Sun Oct 12 11:14:27 PDT 2008


And an interesting side note: now that the speed of the function is
twice as fast, the proportion of time taken up by the memcmp in the
cache has risen to a respectable 4.5%. If making the detoasting
efficient in the other two places has similar effects, the memcmp is
going to move up into the top spot as biggest time user. :)

P.

On Sun, Oct 12, 2008 at 11:11 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 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.
>>>
>>
>



More information about the postgis-devel mailing list