Markus Metz wrote:
assuming that GRASS runs today on systems where at least
500MB RAM are available
500MB total, 500MB per user, or 500MB per process?
It's safe to assume 500MB for the system (although much of GRASS can
run on a PDA, it's reasonable to assume that people won't be
performing complex analysis on such systems), but that doesn't mean
that a single process can use all of it.
Still, the seg mode is slow and testing would require a lot of patience.
GRASS' segement library (which r.watershed.seg uses) is quite
inefficient.
For the segmented r.proj (r.proj.seg in 6.3/6.4, r.proj in 7.0), I
wrote my own tile cache. If it can fit the entire map within the
specified amount of RAM, then it will do so (reading the map directly
into RAM without creating the segment file), without any noticeable
performance impact caused by the extra level of indirection.
If you can't fit the working set into RAM, it's going to be slow
whichever approach you take. Reading into memory which is actually
swap isn't going to be any quicker. Also, using a tile cache allows
you to handle maps which exceed the size of the address space (i.e.
maps larger than 4GiB on a 32-bit system).
OTOH, r.proj does have reasonable locality of reference, so the
working set tends to be small relative to the total amount of data. I
don't know whether the same is true of r.watershed.
--
Glynn Clements [EMAIL PROTECTED]
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
