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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
