[geos-devel] Ability to preallocate the WKT stringstream buffer for really large geometries?

Sandro Santilli strk at keybit.net
Fri Feb 8 04:27:49 PST 2013


On Fri, Feb 08, 2013 at 07:22:21AM +0000, Mats Taraldsvik wrote:

> Have you considered this issue? Do you accept patches to solve this
> by changing the interface (considering GEOS is a port of JTS and follows
> it closely)? :)

I'll be glad to review and apply any patch speeding up WKT writing.
I'm fine with providing an enhanced interface for 3.4.x series,
as long as the old one remains for backward API compatibility.

If you start with that please consider taking a look at
http://trac.osgeo.org/geos/ticket/355 and
http://trac.osgeo.org/geos/ticket/310

Please also make sure the testsuite covers enough cases.

Thank you !

--strk;

> Regards
> 
> Mats Taraldsvik
> 
> > -----Opprinnelig melding-----
> > Fra: geos-devel-bounces at lists.osgeo.org [mailto:geos-devel-
> > bounces at lists.osgeo.org] På vegne av Mats Taraldsvik
> > Sendt: 18. januar 2013 12:53
> > Til: geos-devel at lists.osgeo.org
> > Emne: [geos-devel] Ability to preallocate the WKT stringstream buffer for
> > really large geometries?
> > 
> > Hi,
> > 
> > Generally, I'm very satisfied with the WKTWriter, which is really easy to use,
> > and converts the Geometries to the WKT format. However, when converting
> > _large_ geometries (in this case, contour lines), I get a major decrease in
> > performance.
> > 
> > By looking at the source code (and profiling), I believe the use of a
> > stringstream and hence a dynamically increasing string buffer, constantly
> > reallocating, is causing the performance penalty. Possibly also copying the
> > large string.
> > 
> > Is there anything I can do to improve this scenario? Do you accept
> > contributions to fix this (e.g. passing in the expected size of the resulting
> > WKT string)?
> > 
> > Regards


More information about the geos-devel mailing list