[gdal-dev] Changing default value for GDAL_CACHEMAX ? (was Re: Slow warping)
Even Rouault
even.rouault at spatialys.com
Tue Dec 1 07:51:33 PST 2015
Le mardi 01 décembre 2015 15:54:12, Ari Jolma a écrit :
> 28.11.2015, 17:13, Even Rouault kirjoitti:
> > Le vendredi 27 novembre 2015 13:43:34, Ari Jolma a écrit :
> >> 27.11.2015, 14:10, Even Rouault kirjoitti:
> >>> Try setting GDAL_CACHEMAX to 150 (6048 * 4032 * 3 = 73 MB. and a x 2
> >>> security margin)
> >>
> >> This reduces the time into 4 s.
> >>
> >> Quite a bit reduction from several hours.
> >>
> >> Maybe the default is too low? 150 MB does not seem much.
> >
> > Setting the default is not obvious because it depends on use cases and
> > hardware configurations. What if people run 100 gdal_translate in
> > parallel ? (not very common use cases admidetely, and people can still
> > override the default)
> >
> > Perhaps rather than a fixed value, a percentage of the total RAM would be
> > more appropriate (*). Let's say 5% ?
> > 2 GB (which is the max for a 32 bit process) -> 100 MB
> > 4 GB -> 200 MB
> > 16 GB -> 800 MB.
> >
> > We could also accept a GDAL_CACHEMAX=X% syntax
>
> I that possible? The amount of memory available to a program seems a
> fuzzy topic.
/** Return the total physical RAM, usable by a process, in bytes.
*
* This is the same as CPLGetPhysicalRAM() except it will limit to 2 GB
* for 32 bit processes.
*
* Note: This memory may already be partly used by other processes.
*
* @return the total physical RAM, usable by a process, in bytes (or 0 in case
of failure).
* @since GDAL 2.0
*/
GIntBig CPLGetUsablePhysicalRAM(void)
>
> Ari
>
> > Even
> >
> > (*) the ECW SDK does that for its own purposes, with a 25% default AFAIR
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the gdal-dev
mailing list