Hi Ede,
Seems to be a nice tweak but something is still wrong : the first save is still
very slow.
Seems that the second save of a dataset benefits your optimization, but the
save operation on a freshly imported/extracted dataset is still long.
Also there is something I don't understand : writing a shapefile (a dbf) should
not need FlexibleDateParser at all. The date should simply be converted to a
string by DbfFile.DATE_PARSER. Did you see where and why FlexibleDateParser is
used in the "writing" process ? The problem also exists for JML. I did not
check the code, but I also don't understand why it would need a flexible
"parser"to convert a Date to a String.
Your changed broke two tests, but I removed the tests which were not as
important as the optimization we try to achieve.
---
** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**
**Status:** open
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Mon Aug 17, 2020 07:15 PM UTC
**Owner:** michael michaud
Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb)
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().
---
Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/jump-pilot/bugs/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
