On Wed, Oct 17, 2007 at 04:07:25PM +0200, grass@intevation.de wrote:
Author: hamish
Update of /grassrepository/grass6/vector/v.what.rast
In directory doto:/tmp/cvs-serv29282
Modified Files:
main.c
Log Message:
Add some debug messages to see where the slowdown is.
The slowdown is in the "Updating db table" loop, my guess is
the db_execute_immediate() for each point. Faster to write that
to a stream then execute for all points at once? Only slow for DBF?
To enlarge discussion, I post this here.
Could it be implemented as transaction to speed up?
Markus
------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------
Markus Neteler wrote:
> Update of /grassrepository/grass6/vector/v.what.rast
> In directory doto:/tmp/cvs-serv29282
>
> Modified Files:
> main.c
> Log Message:
> Add some debug messages to see where the slowdown is.
> The slowdown is in the "Updating db table" loop, my guess is
> the db_execute_immediate() for each point. Faster to write that
> to a stream then execute for all points at once? Only slow for DBF?
To enlarge discussion, I post this here.
Could it be implemented as transaction to speed up?
No. v.what.rast encapsulates the whole operation in a transaction
anyhow.
The problem is that the DBMI interface is inherently inefficient for
performing many simple operations. Each SQL statement requires
multiple context switches, at least: client, kernel, driver, kernel,
client, and many more if the communication uses unbuffered I/O.
There is no way to pipeline sequences of commands with the present
interface. Allowing pipelining might speed things up (unless the
overhead is in the database itself), but would result in a more
complex interface. It would be possible to have both pipelined and
immediate interfaces, but there's no point in adding a pipelined
interface unless clients are written to use it.
--
Glynn Clements <glynn@gclements.plus.com>