[GRASS5] v.in.ascii updates

[Helena]

Hamish wrote:
>>It's funny, sqpFreeStmt(st) was realy missing in execute(), I thought 
>>that I had checked it already before. 50000 points - dbf: 100MB ->
>>10MB
> 
> 
> cool.


that is really cool! - thank you both. The 280000 point file that took
30minutes to import while machine was completely frozen now takes 2 minutes
and you don't even know that it is running.
v.in.sites now works well with this data set too.
I haven't tried it with the data that have millions of points yet,
but I am sure that this fixed the major problem.

thanks a lot once more,

Helena
> 
> I can now import the 1.1 million point sample LIDAR data set 
> (lidaratm2.txt.gz, 31.5mb uncompressed) from-
>   http://mpa.itc.it/grasstutor/data_menu2nd.phtml
> 
> According to top, v.in.ascii using that file drives the dbf process up
> to 248mb now and during "Registering lines" part the v.in.ascii process
> goes up to 435mb memory use -- still a few small leaks? re-run valgrind?
> 
> (I don't understand why a point-only vector file is worrying about
> lines?)
> 
> 
> 
>>Thank you Hamish. Should I fix that also in the 6.0 branch?
> 
> 
> seems like a perfect candidate for 6.0.1 to me.
> 
> 
> H
> 
> 
>>Finally Helena can use 6.
>>
>>Radim
>>
>>
>>Hamish wrote:
>>
>>>>>>>I finally got around to installing valgrind to check where the
>>>>>>>memory leaks are.
>>>>>
>>>>>..
>>>>>
>>>>>
>>>>>
>>>>>>Can you do the same for the driver?
>>>
>>>..
>>>
>>>
>>>>The module creates the driver as a new process (fork-exec). I think
>>>>that  you have to use --trace-children=yes.
>>>
>>>
>>>ok,
>>>
>>>CMD="v.in.ascii in=test_pts.dat out=test4 --o"
>>>valgrind -v --tool=addrcheck --leak-check=yes --trace-children=yes
>>>$CMD
>>>
>>>
>>>Memcheck log: 
>>> http://bambi.otago.ac.nz/hamish/grass/memleak/v.in.ascii/memchk_child.txt
>>>
>>>
>>>Look for process 2030 (dbf):
>>>
>>>==2230== 36748400 bytes in 48100 blocks are definitely lost in loss
>>>record 15 of 16 ==2230==    at 0x3414CFE5: calloc
>>>(vg_replace_malloc.c:176) ==2230==    by 0x3416AAB9: sqpInitStmt
>>>(alloc.c:30) ==2230==    by 0x804B09F: execute (dbfexe.c:58)
>>>==2230==    by 0x804D5CA: db__driver_execute_immediate
>>>(execute.c:29)
>>>
>>>
>>>
>>>Also graphical Massif test, heap growth analysis: (end of page)
>>>  http://bambi.otago.ac.nz/hamish/grass/memleak/v.in.ascii/
>>>
>>>
>>>
>>>Hamish