[postgis-devel] Aligned Speed

Paul Ramsey pramsey at opengeo.org
Mon Feb 2 13:12:39 PST 2009


I can't see how this is going to change anything. You've basically
implemented your own version of memcpy. The information is moved from
one memory location to another before it is used.

To take advantage of direct access, I think we are actually going to
have to change the access pattern in the algorithms from one of "pass
in an empty pointer and get it filled" to "request a point and receive
a const pointer back". Or, change the signature of

int getPoint2d_p(const POINTARRAY *pa, int n, POINT2D *point)

to

int getPoint2d_p(const POINTARRAY *pa, int n, POINT2D **point)

or

const POINT2D *getPoint2d_p(const POINTARRAY *pa, int n)

and reference 'point' right into the array.

Paul

2009/2/2 strk <strk at keybit.net>:
> On Thu, Jan 22, 2009 at 05:31:58PM +0100, strk wrote:
>> On Thu, Jan 22, 2009 at 10:19:22AM +0000, Mark Cave-Ayland wrote:
>>
>> > There should be some measurable difference with a fast enough clock, but
>> > as strk points out, the main reason we wish to align is to try and avoid
>> > the overhead of memcpy() when accessing points in large geometries.
>>
>> I wonder how much replacing the memcpy with bitwise ops would
>> speed the thing up...
>
> Attached is an example drop of memcpy from getPoint2d_p.
> If anyone can re-run their tests to use it we can check
> the effects of memcpies ...
>
> --strk;
>
>  Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
>  http://foo.keybit.net/~strk/services.html  /\  Keep it simple!
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>



More information about the postgis-devel mailing list