[GRASS-dev] v.what.rast speedup

[Glynn Clements]

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

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>