[postgis-devel] Aligned Speed
strk
strk at keybit.net
Mon Feb 2 02:22:59 PST 2009
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!
-------------- next part --------------
Index: liblwgeom/lwgeom_api.c
===================================================================
--- liblwgeom/lwgeom_api.c (revision 3569)
+++ liblwgeom/lwgeom_api.c (working copy)
@@ -682,6 +682,12 @@
int
getPoint2d_p(const POINTARRAY *pa, int n, POINT2D *point)
{
+ union {
+ uchar c[8];
+ double d;
+ } u;
+ uchar* ptr;
+
#if PARANOIA_LEVEL > 0
if ( ! pa ) return 0;
@@ -693,7 +699,19 @@
#endif
/* this does x,y */
- memcpy(point, getPoint_internal(pa, n), sizeof(POINT2D));
+ ptr = getPoint_internal(pa, n);
+
+ u.c[0] = ptr[0]; u.c[1] = ptr[1]; u.c[2] = ptr[2]; u.c[3] = ptr[3];
+ u.c[4] = ptr[4]; u.c[5] = ptr[5]; u.c[6] = ptr[6]; u.c[7] = ptr[7];
+ point->x = u.d;
+
+ u.c[0] = ptr[8]; u.c[1] = ptr[9];
+ u.c[2] = ptr[10]; u.c[3] = ptr[11];
+ u.c[4] = ptr[12]; u.c[5] = ptr[13];
+ u.c[6] = ptr[14]; u.c[7] = ptr[15];
+ point->y = u.d;
+
+ //memcpy(point, getPoint_internal(pa, n), sizeof(POINT2D));
return 1;
}
More information about the postgis-devel
mailing list