[gdal-dev] Memory usage for GetProjectionRef

[Frank Warmerdam]

Livneh Yehiyam wrote:
> Hi
> After further investigation I think the situation is more complex, as the results I'm getting depends on the file opened.
> I ran the test with several tiff files and I'm getting completly different results, as described below.
> Also, to rest my mind that this is not a problem with the C# binding, I'v created an identical test using the c interface.
> 
> case 1: 580MB tiff, tiled RGB with pyramid:
> GDALOpen increased the memory by 17KB.
> GetProjectionRef increased the memory by an additional 35KB.
> After calling GDALClose, the memory was still 2KB more than before the call to GDALOpen.
> 
> case 1: 434MB tiff, tiled RGB without pyramid:
> GDALOpen increased the memory by 40KB.
> GetProjectionRef increased the memory by an additional 0.6KB.
> After calling GDALClose, the memory was still 2KB more than before the call to GDALOpen.
> 
> case 3: 420MB tiff, one row per strip RGB without pyramid:
> GDALOpen increased the memory by 186KB.
> GetProjectionRef increased the memory by an additional 0.5KB.
> After calling GDALClose, the memory was still 4KB more than before the call to GDALOpen.
> 
> case 4: 2GB tiff, one row per strip palette packbits compression without pyramid:
> GDALOpen increased the memory by 867KB.
> GetProjectionRef increased the memory by an additional 0.1KB.
> After calling GDALClose, the memory was still 9KB more than before the call to GDALOpen.
> 
> Beside being very inconsistent (or at least I fail to see the pattern), a few things worry me, and might send me searching for another solution:
> 1. opening large stripped files increases the memory by almost 1MB. Multiplied by hundreds of files this amount to hundreds of MBs.
> 2. for a big tiled pyramid file, even the 35KB increase for just reading the projection might be too much.

Livneh,

I can run "gdalinfo utm.tif" under valgrind, a memory corruption and
leak checker, and confirm that no memory is leaked.  I'm not sure what
you are using to check memory use but I have no reason to trust it.

Note that there are memory buffers allocated and kept around for a
variety of purposes.  Some of these are not freed until cleanup functions
like GDALDestroyDriverManager() are called.  These may include cached
copies of the coordinate system .csv files.

You are welcome to go looking for another solution, but I have little
reason to believe GDAL's GeoTIFF driver leaks memory.  If it does
I would be pleased to fix it if you can demonstrate it in a credible way.

I hope you will forgive my disbelief, but I've received so many half
baked claims of memory leaks over the years from folks who don't
understand how heaps work in C programs, how to use leak checking
tools and so forth that my first reaction is usually to disregard
them now.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent