[GRASS-dev] v.what.rast speedup

[Markus Neteler]

Glynn Clements wrote:
> 
> Markus Neteler wrote:
>> >> >> > since v.what.rast is (for me) extremely slow
> ...
>> >> >> Maybe it's the qsort(), maybe it's the i,j loop within a loop.
> ...
>> >> > The loop is certainly inefficient. 
> ...
>> > --- vector/v.what.rast/main.c patch
> ...
>> 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.
> 

It makes things worse: I have killed the job after 6minutes... (DBF).
Compiling again 
without -DUSE_BUFFERED_IO brings me back to 25 seconds.

Running the procedure with SQLite backend as suggested:

time v.what.rast elevpnts rast=elevation.10m col=height
real    0m7.530s
user    0m6.992s
sys     0m0.373s

Running the same procedure connected to PostgreSQL server
on a different machine in intranet:

time v.what.rast elevpnts rast=elevation.10m col=height
real    0m14.085s
user    0m1.419s
sys     0m0.366s

Since SQLite wins, it is not only the DBMI. Still everything is not
extremely fast given that I tested 5000 points but need to work
with 300k points for my real work (ideally for several thousand
maps).

Markus
-- 
View this message in context: http://www.nabble.com/r.random%3A-now-with-optional-cover-map-parameter-tf4634057.html#a13339117
Sent from the Grass - Dev mailing list archive at Nabble.com.