Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#3403 closed enhancement (wontfix)

Deserialize PostGIS geometry directly into GEOSGeometry

Reported by: dbaston Owned by: pramsey
Priority: low Milestone: PostGIS 2.2.1
Component: postgis Version: 2.2.x
Keywords: Cc:


Bypassing LWGEOM intermediate form can save a number of palloc/pfree cycles, which can be relatively expensive in the case of large MultiPoints.

Change History (3)

comment:1 by dbaston, 8 years ago

Resolution: wontfix
Status: newclosed

I'm creating this ticket as documentation of what I consider a failed experiment. I created these routines and while the relative performance boost can be high, the absolute time savings is unlikely to matter in any realistic scenario. If you're getting a centroid of 1 million points, you don't care if it takes 2 seconds or 1 second, and if you're getting the centroid of a billion points, you'll probably run out of memory before you're worried about CPU cycles.

In short, the benefits are few and don't justify the increased code volume.

comment:2 by pramsey, 8 years ago

I'll comment here, but the "ultimate" goal for this performance point is to enhance GEOS sufficiently that it can use the underlying POINTARRAY memory as the backing store for it's own CoordinateSequences, so we don't need to memcpy coordinates at all. Now, as you've noticed, it's always going to be a relatively small win, since we're usually calling GEOS when we have something expensive to do. But if you're interested in the postgis/geos integration performance space, upgrading GEOS to use external memory for CoordinateSequences is one possibility.

comment:3 by dbaston, 8 years ago

I'm not sure if this is possible without very significant changes to GEOS. On the face of it, you should be able to write a class (LWCoordinateSequence, say) that implements the CoordinateSequence interface and directs all access to an underlying POINTARRAY. The problem is that implementing a CoordinateSequence requires that you return references to GEOS Coordinate objects (for example, const Coordinate & getAt(std::size_t index) ), which in turn requires those Coordinate objects to actually exist for the lifetime of the CoordinateSequence. And since Coordinates are used throughout the library by direct access to their xyz member variables, I don't think it's possible to make a wrapper for, say, POINT3D, to allow it to function as a Coordinate during its journey through GEOS.

Note: See TracTickets for help on using tickets.