[GRASS-dev] r.surf.contour inefficiency?

[Glynn Clements]

Markus Metz wrote:

> > Following r.cost @ 100%, I have changed cseg_open(16, 16, 8) to 256,256,64
> > locally. 
> 
> FWIW, I found that r.watershed.seg is fastest with the equivalent of 
> cseg_open(200, 200, <variable number of open segments>). It seems 
> logical to use powers of 2, but 200, 200 is in r.watershed.seg faster 
> than 128, 128 and 256, 256.

Using powers of two only provides a benefit if the code actually takes
account of this restriction; the segment library doesn't:

	int segment_address(const SEGMENT * SEG, int row, int col, int *n, int *index)
	{
	    *n = row / SEG->srows * SEG->spr + col / SEG->scols;
	    *index = (row % SEG->srows * SEG->scols + col % SEG->scols) * SEG->len;

OTOH, r.proj uses a fixed 64x64 block size, and the "get" operation is
a macro. Other sizes would work, but there is an efficiency gain for
fixing the size at compile time.

But, if the nature of the algorithm is such that processing time
becomes a problem long before memory does, then there's no point to
using any form of segmentation.

-- 
Glynn Clements <glynn at gclements.plus.com>