[GRASS-dev] comparing r.cost and r.terracost

[Markus Metz]

Same test region as before

North Carolina sample dataset

g.region rast=elev_state_500m at PERMANENT res=100
# gives about 28 million cells
v.to.rast nc_state at PERMANENT use=val val=500.0 out=cost --o
v.to.rast urbanarea at PERMANENT use=val val=1 out=urbanarea --o
r.cost in=cost start_rast=urbanarea out=dist_urban percent_memory=20 --o

grass7 r.cost
real    0m55.349s
user    0m53.360s
sys    0m1.797s

grass65 r.cost
real    26m35.166s
user    2m55.612s
sys    23m37.921s

r.terracost: check optimal tile size for 400MB memory (default setting; 
r.cost in grass7 used 135MB with 20% of maps in memory)
r.terracost in=cost start_rast=urbanarea out=dist_urban_terracost -i
[...]
TILESIZE: nc_spm_08 N=28064550 elements, M=419430400 bytes, optimal 
numtiles=1870

r.terracost numtiles=1870, intermediate data are stored on disk as 
r.cost does
real    25m13.593s
user    22m46.978s
sys    1m8.059s

r.terracost numtiles=1, all in memory (just fits into 400MB)
real    0m17.969s
user    0m17.276s
sys    0m0.500s

According to Laura Toma, when comparing r.cost with r.terracost, 
numtiles must be >1 for r.terracost in order to compare disk I/O 
algorithms [1]

With these test settings that intentionally reduced memory consumption 
in order to test disk I/O performance, r.terracost is not really faster 
than r.cost in grass65 and much slower than r.cost in grass7.

Markus M

[1] http://lists.osgeo.org/pipermail/grass-dev/2009-July/045157.html