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. -----Original Message----- From: Chaitanya kumar CH [mailto:[email protected]] Sent: Tuesday, October 05, 2010 9:36 AM To: Livneh Yehiyam Cc: gdal-dev Subject: Re: [gdal-dev] Memory usage for GetProjectionRef Livneh, I am assuming the 80KB refers to the memory change for getting the projection and not the whole dataset. Can you check if the 80KB memory is freed and not leaked if the dataset is closed? On Mon, Oct 4, 2010 at 10:41 PM, Livneh Yehiyam <[email protected]<mailto:[email protected]>> wrote: Hi We are using Gdal 1.7.0b from FWTools 2.7.1. Our application is written in C#. In our application we need to open a large number of tiff files (more than 2000). We noticed that opening a dataset and then getting the projection string will increase the amount of memory (private bytes) by more that 80KB. This seems not a large amount, but multiplied by 2000 is more than 160MB. Is anyone aware of such a problem? Sent from my mobile ________________________________ This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:[email protected]<mailto:[email protected]> and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ________________________________ _______________________________________________ gdal-dev mailing list [email protected]<mailto:[email protected]> http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ********************************************************************************************** This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:[email protected] and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. **********************************************************************************************
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
