[GRASS-dev] Raster format and dual function module

[Hamish]

> > > 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.
..
> 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.

tip: r.mapcalc lets you set intermediate variables, see eval():
  http://grass.ibiblio.org/grass61/manuals/html61_user/r.mapcalc.html

(maybe someone who knows this better can provide an example?)


> 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...

The act of writing will mean the data will pass through system memory
and be cached. I am not qualified to say much further about it, other
than it happens and correct tuning of this is what the kernel
developers spend lots of time trying to get right.



Hamish