> > 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 > >> > [email protected] > >> > http://lists.osgeo.org/mailman/listinfo/grass-dev > >> > > _______________________________________________ > > grass-dev mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/grass-dev > > > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
