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

Glynn Clements glynn at gclements.plus.com
Sun Feb 8 11:25:20 EST 2009


Markus Neteler wrote:

> > I'll remove the segmentation code in 7.0.
> 
> Here the timing comparison:
> 
> # NC data set
> g.region vect=elev_lid792_cont1m res=1 -p
> v.to.rast elev_lid792_cont1m out=elev_lid792_cont1m use=z
> time r.surf.contour elev_lid792_cont1m out=dem
> 
> Results:
> * GRASS 6.5.svn (pre seg size update):
> 147.66user
> 24.14system
> 2:52.22elapsed
> 184inputs+4544outputs (1major+508minor) pagefaults 0swaps
> 
> * GRASS 6.5.svn (post seg size update):
> 118.28user
> 0.26system
> 1:58.93elapsed
> 0inputs+4984outputs (0major+1202minor)pagefaults 0swaps
> 
> * GRASS 7.svn:
> 72.19user
> 0.04system
> 1:12.38elapsed
> 0inputs+320outputs (0major+1023minor) pagefaults 0swaps
> 
> r.univar doesn't show differences between 6.5.svn (post seg size update)
> and 7.svn.

How does r.univar come into this?

> Is there risk in backporting this?

The only risk is that I might have made a mistake somewhere. Mostly
the change just removes all references to the segment library and uses
an array insted.

[Note to self: remove segment library from Makefile.]

The nature of the change is such that it would be hard to make a
mistake that would only show up in specific circumstances. If a
straightforward test case works, it should be fine.

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


More information about the grass-dev mailing list