[GRASS-dev] Re: [GRASS-user] GRASS 7 vector topology format changed

[Hamish]

Markus Metz wrote:
> IOW, the bounding boxes are not
> gone, they are still there, but no longer stored in two
> different locations, only in one location.
...
> No, the new, reduced format performs better with larger
> datasets. For small datasets, there should be not much of a
> difference in terms of speed, only in terms of memory
> requirements.

(formerly we'd get to about 3 million points on a system with
~ 2gb ram)


> > is time to run d.vect in a sub-region of the overall
> > map a good way to test the performance difference?
> >
> Maybe, but d.vect is not very efficient: it goes through
> all features, checks if a feature is inside the current region
> and reads e.g. every area and the area's isles twice instead of
> only once.
> v.what, v.build, v.in.* are also good to test performance
> differences.

ok, I meant something which made heavy use of the bounding boxes.
I guess the others do it in a less obvious way to the end-user.

> Also note that database operations can mask effects
> of changed topology management because database management
> can be the main time consuming factor (e.g. [r|v].in.lidar).

one thing I noticed recently in 6.x.svn was that 'v.out.ascii
column=' was terribly slow, it seemed to open/close the dbf
db for every category. a vector with only 50000 points was taking
minutes to run.

[OT]
re. r.in.lidar, I worry about that much cloned code.
It is a shame that the #ifdef + Makefile solution to building
two modules from one set of code is problematic, as that would be
an ideal solution. (see recent r.colors, r3.colors frontend
wrappers instead, although I wonder if you could still use pre-
processor macros if the front-end wrapper #define'd them instead
of asking the Makefile to do it? hmm maybe not, there is still
just one set of *.o files)

I just have bad flashbacks of spending a lot of time re-sync'ing
fixes to i.points, i.vpoints, ..., after their cloned graphing
code had diverged for many years.


> > (hoping this means we can have the best of both worlds!)
> >
> That's the aim.

great,
Hamish