[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