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

[Hamish]

> Hamish wrote:
> > while running r.surf.contour I notice that 33% of the cpu is dealing
> > with "sys" leaving ~ 65% to run the program.
....
> > there is no big disk I/O going on -- is using that much "sys" CPU
> > indicative of some massive inefficiency in the program? It's a module
> > which has historically taken a ridiculously long time to run and I
> > don't understand why the kernel needs to be involved so much.

Glynn:
> I presume that it's the use of the segment library causing a lot of I/O.
> 
> Can r.surf.contour reasonably be used on gigabyte-sized maps?

currently it is so slow to run that working with such a big map would
not complete in a reasonable time.


> If not, I'd suggest eliminating the use of the segment library.
> 
> In general, there isn't much point using segmentation with algorithms
> whose time complexity is worse than linear in the size of the input. 
> On modern systems, the run time will typically become prohibitive
> before memory usage does.
> 
> If it can reasonably be used on maps which won't necessarily fit into
> memory, try increasing the number of segments in memory (the last
> parameter to cseg_open(), currently hardcoded to 8).
> 
> Even if that reduces the sys time, segment_get() is still vastly
> slower than array access. If segmentation is useful, the code in
> r.proj[.seg] should be significantly more efficient, due to the use of
> macros, power-of-two sizes, and compile-time constants.

Following r.cost @ 100%, I have changed cseg_open(16, 16, 8) to 256,256,64
locally. now "sys" CPU time is greatly reduced:

Cpu(s):  1.3%us,  0.3%sy, 96.7%ni,  0.0%id,

and memory use by the module is 25mb for a 2700x1090 region.

it's running now, we'll see how much faster it goes.


of course r.surf.contour has other big problems, like the fact that it
only outputs CELL maps and you have to multiply your F/DCELL input DEM by
10000 before running and divide by the same afterwards to preserve sub-
meter elevation, and (IIRC) if you have a "0" contour it is treated as
NULL. so: 'r.mapcalc surf_input=(dem*10000)+1'
None the less it really does a very nice job WRT the output, so can be
worth the pain.


thanks,
Hamish