[GRASS-user] v.lidar.edgedetection very slow

Michael Perdue michael_perdue at yahoo.ca
Fri Jun 19 12:48:33 EDT 2009

I actually get the same thing. For the first while the process runs in  
full use of one core, but once the process starts writing results to  
the db, the whole process bogs down to a grinding halt. CPU usage for  
v.lidar.edgedetection drops down to ~1% (1% of one core) and sqlite  
usage rises to ~16%. Maybe I'm wrong, but my impression was that the  
bottle neck was the modifications to the database.

>> However, I have not finished a process yet as it writes at about
>> 1kb per second, using 1% of cpu.
> I can only assume that is due to page swapping. Running without a DB
> and with no topology may help to save quite a bit of memory/time  
> there.
> no idea why it would drop to 1% of CPU if there is no page swapping
> going on.
>> As it is writing the file (was at 6Mb after 3hrs), the mem usage is
>> on 114Mb with 1.4Gb free at the moment. It is not using the PageFile.
> .... is that at 100%/4(25%) or 1% CPU?

On 19-Jun-09, at 5:43 AM, John Tate wrote:
> Also, when I have tried to run v.oultier without db/topology it says  
> it cannot as there is no database.  I will look at this again later.  
> Maybe I am not selecting 3D when I have tried without db etc.

Note that there is a bug in v.outlier. v.outlier creates a temporary  
table by the name of outfilename_aux (LN #137 /lidar/v.outlier/main.c)  
but elsewhere in the code it is hardwired to Auxiliar_outlier_table  
(LN's # 239 & 258 /lidar/v.outlier/outlier.c) , so when it actually  
tries to write to the table it complains and fails. You can get around  
it by manually creating this table using;

db.copy from_table=outfilename_aux to_table=Auxiliar_outlier_table

I'm not sure why, but it looks like the system doesn't always need to  
use the Auxiliar_outlier_table, and when it doesn't, it continues on  
merrily without complaint. Unfortunately, when it does require the  
table, on my system the program continues on only to segmentation  
fault further down the line (at least it does on my system). Maybe  
it's because of the changes that I made to the code to correct the  
above error, but I can't see why that would be true. I was planning on  
looking further into it, but haven't had the time to start debugging.  
In the mean time I've added the files with my changes to the code for  
the developers. I'm a hack, so the changes are probably in poor coding  
practice. Someone more savvy that I will need to clean it up.



PS. IF I find what I think are errors or possible improvements to the  
code, what is the most appropriate place and method to submit them?

-------------- next part --------------
Skipped content of type multipart/mixed

More information about the grass-user mailing list