[GRASS-dev] v.what.rast speedup
glynn at gclements.plus.com
Mon Oct 22 00:40:49 CEST 2007
Markus Neteler wrote:
> >> >> > since v.what.rast is (for me) extremely slow, I have added
> >> >> > cover map support to r.random.
> >> >> ..
> >> >> > PS: v.what.rast still running on just 300k points while I
> >> >> > implemented above :-) Anyone who could make v.what.rast faster?
> >> >>
> >> >> Maybe it's the qsort(), maybe it's the i,j loop within a loop.
> >> >
> >> > The loop is certainly inefficient. Rather than shifting the entire
> >> > array down every time it finds a duplicate, it should keep separate
> >> > source and destination indices, e.g. (untested):
> >> >
> >> > for (i = j = 0; j < point_cnt; j++)
> >> > if (cache[i].cat != cache[j].cat)
> >> > cache[++i] = cache[j];
> >> > else
> >> > cache[i].count++;
> >> > point_cnt = i + 1;
> >> I am afraid to say that I don't know how to implement the suggestion
> >> in v.what.rast...
> > --- vector/v.what.rast/main.c 17 Oct 2007 14:07:23 -0000 1.26
> > +++ vector/v.what.rast/main.c 21 Oct 2007 17:52:42 -0000
> > ... patch
> Thanks (for your patience): I have made a Spearfish test:
> g.region rast=elevation.10m
> r.random elevation.10m vect=elevpnts n=5000 --o
> v.db.addcol elevpnts col="height double precision"
> # old
> time v.what.rast elevpnts rast=elevation.10m col=height
> real 0m25.253s
> user 0m24.756s
> sys 0m0.308s
> # new
> real 0m24.040s
> user 0m23.707s
> sys 0m0.297s
> Interestingly, timing rather identical (also for 1000). Using the DBF
> driver here.
It was subsequently suggested that it may be the database access which
is the main performance issue. Personally, I suspect that is probably
You could try re-compiling the DBMI libraries with -DUSE_BUFFERED_IO
to see if that helps at all.
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev