[postgis-devel] Make war on LWGEOM_INSPECTED

Paul Ramsey pramsey at opengeo.org
Fri Nov 19 08:19:24 PST 2010


On Fri, Nov 19, 2010 at 8:13 AM, Olivier Courtin
<olivier.courtin at oslandia.com> wrote:
>> If you did them
>> with the stringbuffer_t ala the new lwout_wkt.c the code would get
>> much smaller at least. If you don't want to do it, let me know and
>> I'll do it instead. But it must go, since it's just a wrapper on top
>> of the serialized form.
>
> Few month ago i already try to rewrite AsGML with stringbuffer
> I was impressed by the size of the code (so pretty indeed)
>
> But the performance was poorer, something like 20-30% if i recall.
> I didn't took time since to investigate why and if it could be significantly
> improved

Interesting, I figured the cost of memory reallocation in the
stringbuffer would be offset by the savings of not traversing the
geometry twice. BTW, the memory cost should be lower in PgSQL than in
bare liblwgeom because a palloc is a lot faster than a malloc.

The obvious way to save time is to preallocate more room in the
stringbuffer, so the number of reallocations is lowered. Perhaps a
simple metric that counts vertices first would provide enough of a
guide to allocate "enough" space to avoid a reallocation in the
buffer. Memory is cheap these days.

> On the timing aspect, is it something you want to be done ASAP
> or it could be postpone till very end of December ?

I would be hoping for sooner than later. My current goal is to remove
all functions that work with serializations directly, getting all that
functionality hidden under the ptarray API. You have good regression
suites, so I don't feel too scared about doing it myself if you're too
busy.

P



More information about the postgis-devel mailing list