[postgis-devel] Memory Leak (Two Senses)

[Mark Cave-Ayland]

Paul Ramsey wrote:

> Thanks for all the detailed info, Mark!
> 
> I agree that our LWGEOM data structure should be aligned and directly
> accessible, but I would go one further and say we should align our
> serialized structure. Basically retain the aspect of Dave's design
> that uses the serialized version directly, but alter the serialized
> version enough to align it internally.
> 
> Why so? As you note, that data is const, we can't muck with it.
> HOWEVER, most operations people are running in the database are
> read-only with respect to the spatial data. They are using it as a
> query parameter, or a filter, or they are just flipping it out to a
> different format (maps, or GML, JSON or whatnot).  AND, in those cases
> where geometry IS being altered, it is usually being done in a
> constructive manner: that is, whole new geometries are being created
> (buffer, union, difference, etc).

Yeah I can see the advantages in this, but of course there are lots of 
implications. Users would have to dump/restore their databases for one, 
and there would also be an increase in the size of data on disk (imagine 
the padding required for a 64-bit system...).

> I think where we both end up is in a place where we need some way of
> noting what kind of geometry we have on hand, a const one or a
> variable one, so we can "do the right thing" in a number of situations
> (freeing, trying to alter, etc).

You got it :)

> And think, if you're getting that good throughput memcpy'ing the whole
> block, how fast will it be when you're directly accessing an aligned
> tuple? :) W00t!

I suspect it would be fairly fast; but I'd like to see some concrete 
numbers from a suitable test to ensure that the alignment/disk size 
tradeoff does actually have a measurable improvement over just a plain 
aligned memcpy().


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063