this bug's URL: http://intevation.de/rt/webrt?serial_num=2904
Request number 2904 was commented on by 'guest' (guest user).
Responding to this message will send mail to the requestor.
Request Tracker
rt@intevation.de
--------------------------------------------------------------
Cc: grass5@grass.itc.it
I tried to track down the problem - here is more detailed info, but no
solution yet:
The transfering of sites to vector file seems to slow down as the number
of points increases (maybe db_append_string has to go through everything
that has been written each time it adds a new point?)
but the real problem seems to be in db_close_database(driver) -
the program spends by far the most time on that function,
for illustration, 280000 points takes 3 minutes doing the transfering sites
to vect file but it spends 8 minutes on db_close_database and it extremely
slows down the machine (windows, mouse practically don't work on my computer
during those 8 minutes). Everything else runs for a negligible time.
Slower importing of 280000 points is not really a problem, but
for larger files (500000+) I was unable to get it past
db_close_database(driver) after running it for hours.
So the bug apperas to be somewhere in lib/db/dbmi_driver/d_closedb.c or
d_close_cur.c, but I am only guessing here.
-------------------------------------------- Managed by Request Tracker
It will be in the driver implementation of db__driver_close_database(),
either in save_table() or free_table() in grass51/db/drivers/dbf/db.c.
Can you please try to comment the free_table (i); ( row 110 )
in the grass51/db/drivers/dbf/db.c.
In theory, one driver can be reused for another database, but AKAIK
it is not in current GRASS. So it is faster just close the driver.
OTOH, it can become a problem if DBMI swith to dlopen because of windows port.
Radim
guest user via RT wrote:
this bug's URL: http://intevation.de/rt/webrt?serial_num=2904
Request number 2904 was commented on by 'guest' (guest user). Responding to this message will send mail to the requestor.
Request Tracker
rt@intevation.de
--------------------------------------------------------------
Cc: grass5@grass.itc.it
I tried to track down the problem - here is more detailed info, but no
solution yet:
The transfering of sites to vector file seems to slow down as the number
of points increases (maybe db_append_string has to go through everything
that has been written each time it adds a new point?)
but the real problem seems to be in db_close_database(driver) -
the program spends by far the most time on that function,
for illustration, 280000 points takes 3 minutes doing the transfering sites
to vect file but it spends 8 minutes on db_close_database and it extremely
slows down the machine (windows, mouse practically don't work on my computer
during those 8 minutes). Everything else runs for a negligible time.
Slower importing of 280000 points is not really a problem, but
for larger files (500000+) I was unable to get it past
db_close_database(driver) after running it for hours.
So the bug apperas to be somewhere in lib/db/dbmi_driver/d_closedb.c or
d_close_cur.c, but I am only guessing here.
-------------------------------------------- Managed by Request Tracker
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5