[GRASS-dev] Raster format and dual function module
Joel Pitt
joel.pitt at gmail.com
Thu May 25 03:20:25 EDT 2006
On 5/25/06, Hamish <hamish_nospam at yahoo.com> wrote:
> > This is due to another frustration I've had with speed of execution.
> > While running long chains of commands in simulations I can't help
> > realising that every command has to reload a map from disk and then
> > write it back. As we all know, disk access is REALLY slow in
> > comparison to memory etc. so if GRASS modules were compiled as
> > libraries the last N (N being configurable) number of loaded maps
> > could remain in memory for quick processing and display.
>
> Your OS should cache the data in non-reserved memory space and reuse it
> if possible, or dump it if something else wants the space.
>
> e.g. grep for something in the grass source code, then when it is done
> try it again. The second time will finish in 5% of the time as it wasn't
> reading from the disk. The more memory you have, the more potential for
> cache space.
>
Okay, good point about reading maps, however the writing still takes
time and writing to disk is the only simple way for passing a map from
one command to the other.
Unless the OS doesn't actually write the file when it is closed. Which
I'm guessing would be a Bad Thing (TM)
BTW, do you know whether a newly written file also changes the OS
cached version? Or in other words, is the cache invalidated after a
write changes the disk? Just curious...
--
"Wish not to seem, but to be, the best."
-- Aeschylus
More information about the grass-dev
mailing list