Hamish wrote:
Markus Metz wrote:
The original version uses very little memory, so assuming that GRASS
runs today on systems where at least 500MB RAM are available I changed
the parameters for the seg mode, more data are kept in memory, speeding
up the seg mode. Looking at other modules
Markus Metz wrote:
Right now I don't want to introduce a new option to give the user control
over how much memory is used (be it MB memory, number of rows or percent
of the map) because I want to keep all options of r.watershed.fast
identical to the original version.
adding new options is ok
Markus Metz wrote:
Right now I don't want to introduce a new option to give the user
control over how much memory is used (be it MB memory, number of rows or
percent of the map) because I want to keep all options of
r.watershed.fast identical to the original version.
There's no reason to
Hamish wrote:
and other modules like r.in.xyz have percent= (0-100) for how much of the
map to keep in memory at once.
I'm wondering if it would be worth adding a switch to r.in.xyz to
indicate that the points have been pre-sorted in descending order of
their Y coordinate (which can be done
Markus Metz wrote:
The original version uses very little memory, so assuming that GRASS
runs today on systems where at least 500MB RAM are available I changed
the parameters for the seg mode, more data are kept in memory, speeding
up the seg mode. Looking at other modules using the segment
