[GRASS-dev] [GRASS GIS] #2035: v.kcv optimization

[GRASS GIS]

#2035: v.kcv optimization
-------------------------+--------------------------------------------------
 Reporter:  mmetz        |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  Vector       |     Version:  svn-trunk                
 Keywords:  v.kcv        |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by mmetz):

 Any testing of v.kcv must ensure that there is no bias both in the point
 selection and the partition assignment. Thus a 2-step random selection
 process seems to provide the least biased results: 1. randomly select a
 point, 2. randomly assign a partition to this point. This is what v.kcv
 does in GRASS 6, but in a very inefficient way.

 v.kcv has been optimized in trunk r57231.

 Some testing with vectors in the North Carolina dataset:

 Vector geonames_wake with 1088 points copied to the sqlite mapset:

 {{{
 g.copy vect=geonames_wake,my_geonames_wake

 # g6
 time v.kcv in=my_geonames_wake out=my_geonames_wake_kvc col=part k=10

 real    2m27.108s
 user    0m0.979s
 sys     0m0.754s

 # with db_[begin|commit]_transaction() added to local copy
 real    0m1.931s
 user    0m0.742s
 sys     0m0.358s

 # g7
 v.kcv map=my_geonames_wake col=part k=10

 real    0m0.625s
 user    0m0.133s
 sys     0m0.068s

 }}}


 Vector geodetic_pts with 29939 points copied to the sqlite mapset:

 {{{
 g.copy vect=geodetic_pts,my_geodetic_pts

 # g6 with db_[begin|commit]_transaction() added to local copy
 v.kcv in=my_geodetic_pts out=my_geodetic_pts_kvc col=part k=10

 real    3m26.652s
 user    2m52.859s
 sys     0m30.714s

 # g7
 v.kcv map=my_geodetic_pts col=part k=10

 real    0m4.813s
 user    0m2.836s
 sys     0m1.527s
 }}}

 In GRASS 7, about 70% of the processing time are used by the database
 driver sqlite for a vector with about 120 000 points (not feasible to
 process in GRASS 6). Any further optimization should thus look at the
 sqlite driver, or even sqlite itself instead of the v.kcv module.

 For GRASS 6, I would recommend to add db_[begin|commit]_transaction().

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2035#comment:2>
GRASS GIS <http://grass.osgeo.org>