<div dir="ltr">David,<div><br><div class="gmail_extra">I see I misunderstood about the free and it is already documented.  So I think the docs are good now and that most users should never even need to think about the caching aspect.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Best regards,</div><div class="gmail_extra">Frank<br><br><div class="gmail_quote">On Fri, May 31, 2013 at 4:38 PM, Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">David,<div><br></div><div>Note that the image cache will start discarding blocks on it's own when it is full.  I think the default cache is about 64MB.    I don't think that flushing the cache should be part of normal applications operations, though if you are very tight on memory you might want to alter the default size.  Note that the cached blocks are discarded when the dataset is closed.</div>

<div><br></div><div>I will update the example to free the buffer at the end. </div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Best regards,</div><div class="gmail_extra">Frank</div><div class="gmail_extra">

<br><div class="gmail_quote"><div><div class="h5">On Fri, May 31, 2013 at 4:24 PM, David Strip <span dir="ltr"><<a href="mailto:gdal@stripfamily.net" target="_blank">gdal@stripfamily.net</a>></span> wrote:<br></div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">

  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    I'm reading a fairly large (at least to me) geotif (about 2GB) a
    line at a time. I noticed that memory usage increases as I read the
    image. It appears that what's going on is that the driver hangs onto
    these lines of the image, even though I'm providing the same buffer
    for it to read into each time. At this point I noticed the
    FlushCache method. Calling this after each reading each scan line
    solves the problem of the growing memory usage. <br>
    <br>
    I assume this behavior of caching whatever is read is deliberate. I
    think it would be useful in the API examples to make this behavior
    clear and perhaps show the use of the FlushCache method. <br>
    For example, the API Tutorial page shows this for how to read a line
    into a buffer:<br>
    <blockquote> <b><big><big>Reading Raster Data</big><br>
        </big></b>There are a few ways to read raster data, but the most
      common is via the GDALRasterBand::RasterIO() method. This method
      will automatically take care of data type conversion, up/down
      sampling and windowing. The following code will read the first
      scanline of data into a similarly sized buffer, converting it to
      floating point as part of the operation.<br>
      <br>
      In C++:<br>
      <br>
              float *pafScanline;<br>
              int   nXSize = poBand->GetXSize();<br>
      <br>
              pafScanline = (float *) CPLMalloc(sizeof(float)*nXSize);<br>
              poBand->RasterIO( GF_Read, 0, 0, nXSize, 1, <br>
                                pafScanline, nXSize, 1, GDT_Float32, <br>
                                0, 0 );<br>
      <br>
      The pafScanline buffer should be freed with CPLFree() when it is
      no longer used.<br>
    </blockquote>
    I think it would be useful to point out, in addition to the need to
    CPLFree the buffer that if you are using this example in a loop to
    read the image a line at a time, you should FlushCache every line
    (or periodically) to keep from accumulating the entire image in the
    cache (which is invisible to the user). It seems (to me) that it
    would be better to put this in the API Tutorial rather than as a
    code snippet in the Wiki, since the tutorial is where most people
    would look when starting out.<br>
    <br>
    <br>
    <p><br>
    </p>
    <br>
  </div>

<br></div></div>_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br>
<br clear="all"><div><br></div>-- <br>---------------------------------------+--------------------------------------<br>
I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>

and watch the world go round - Rush    | Geospatial Software Developer<br>
</font></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush    | Geospatial Software Developer<br>
</div></div></div>