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
