[gdal-dev] GDAL memory management

Even Rouault even.rouault at spatialys.com
Thu Apr 30 02:24:40 PDT 2020


Jesús,

> 
> I have been working with C/C++ and GDAL with GEOS for some time now and I
> have a question about GDAL memory management.
> 
> I wonder if there are any memory management options or tips to control
> allocations and deallocations in the library since we are noticing
> performance problems as our data increases in complexity, mainly OGR
> operations (intersection, simplify).
> 
> For example, I would expect something to do the same as:
> - std::allocator: http://www.cplusplus.com/reference/memory/allocator/
> - CGAL allocator:
> https://doc.cgal.org/latest/Manual/devman_memory_management.html
> - SQLite memory allocation routines:
> https://www.sqlite.org/c3ref/mem_methods.html
> 
> I have been looking for it, but GDAL is so big that maybe I missed
> something.

Interaction between GDAL and GEOS is in ogr/ogrgeometry.cpp and ogr/
ogrgeometryfactory.cpp

Basically GDAL will export geometries to WKB and GEOS will instanciate its geometry object 
from it. The temporary WKB buffer created by GDAL is using CPLMalloc() that is just a 
wrapper over malloc().
GEOS will likely use standard C++ memory operators (new, vector) etc.
And ultimately GDAL will reconstruct a OGR Geometry from a GEOS WKB buffer, using a mix 
of C++ new and CPLMalloc

From the links you refering, it seems you'd want a way to use your own memory management 
routines. There's no such possibility in GDAL. CPLMalloc()/CPLRealloc()/CPLFree() could 
possibly be redirected to some callbacks.  On the C++ side, not sure what would be involved.

Are you really sure that the bottleneck you see are in memory allocations/deallocations 
themselves ? I'd expect more computational complexity to be the main limit.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200430/cd32fc54/attachment.html>


More information about the gdal-dev mailing list