mark.cave-ayland at siriusit.co.uk
Sun Dec 14 13:27:27 PST 2008
Paul Ramsey wrote:
> I'm looking at the simple distance calculating function, and I see this:
> We're just reading, why the memcpy? Sure, it's pretty darn fast, hand
> optimized assembler by the gods of gcc and all that, but surely it
> would nicer to just get a pointer into a structure.
> All this derives from having our point arrays stored in "uchar
> *serialized_pointlist" the primary advantage being ... ? Comments say
> that we don't have to worry about 2/3/4D. OK, I can see that. But...
> wouldn't an "double *pointlist" work even better? We could reference
> into it with accessors just as currently, but we wouldn't need the
I'm fairly sure it was there to allow access to unaligned data (i.e. not
on a word boundary).
> I'm still grasping at this stuff, deeper thoughts desperately wanted.
> BTW, I'm doing a project that involves some simple computational
> geometry and implementing some extra primitives native to PostGIS, and
> building unit tests with cunit (I feel much more confident testing
> each little block of code along the way). Unfortunately I'm building
> against 1.3, which makes things well-nigh impossible. I think I might
> have to flip this project around and develop on 1.4 using liblwgeom,
> then back-port for the client, or I'll be spending all my time
> scabbing bits of liblwgeom into my framework instead of working on the
> actual code.
Yup indeed. I've been a complete 1.4 convert for several months now,
mainly because the debugging capability is so much superior. So I tend
to do all the hard digging/tracing in trunk and then backpatch to 1.3
when I'm done.
Sirius Corporation - The Open Source Experts
T: +44 870 608 0063
More information about the postgis-devel