[GRASS-dev] Speeding up v.out.ogr (again)

[Benjamin Ducke]

>
> I think it's rather the dblib than v.out.ogr. Recently I have fixed a
> few memory leaks in dblib, but no optimizations. The dbf driver in
> particular is terribly slow. An index like for real database backends
> might help, although that would need to be created on the fly since
> dbf does not support indexes. Nevertheless, I noticed that a lot can
> be done on module level. The new v.out.ply addon for example is based
> on v.out.ascii, and v.out.ply with attribute export is magnitudes
> faster than v.out.ascii with attribute export.
> 
> Markus M
> 

OK then. For the time being, I will continue to experiment with
my own fork of v.out.ogr, and will report back if I make any
progress.

Best,

Ben

> >>
> >>
> >> >> >
> >> >> > If so, then I suggest putting in a condition, so that those
> >> >> > GRASS maps that have just one attribute table can perform
> >> >> > the SQL SELECT outside of mk_att(). Otherwise, we punish
> >> >> > all GRASS users with extremely slow export speed, even though
> >> >> > most of them might not even use multi-table attributes in
> >> >> > their projects. The difference in my test was something like
> >> >> > factor 500!
> >> >>
> >> >> Please test if attribute assignment is preserved and attributes are
> >> >> not randomly swapped. A stream vector created with r.stream.extract
> >> >> would be a good test case.
> >> >>
> >> >
> >> > Will do.
> >> >
> >> > Ben
> >> >
> >> >> Markus M
> >> >>
> >> > _______________________________________________
> >> > grass-dev mailing list
> >> > grass-dev at lists.osgeo.org
> >> > http://lists.osgeo.org/mailman/listinfo/grass-dev
> >>
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
> >
>