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

[Markus Neteler]

On Sun, Feb 8, 2009 at 5:25 PM, Glynn Clements <glynn at gclements.plus.com> wrote:
> 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?

Forgot to mention that I used r.mapcalc to calculate the differences
between the 6.5 and 7 results.

>> 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.

Here it does. Some Mac tests would be good.

Markus