Indeed, from my tests, things are getting worst :
I save my dataset to a shapefile after it has been freshly extracted from a
database (it contains a geometry and a timestamp)
1.15 : 1st save : 55s
2nd save < 1s
r6382 : 1st save : 188s!
2nd save < 1s
Another thing about your explanation : I remember that you introduced the
LazyConversion of attributes with the json parser. I think the reason was
related to the type system of json (which has only strings, numbers and
boolean). In the case of shapefile or database where data is precisely typed, I
think the lazy conversion is finally very costly. Data should be stored with
the right type at the first place. It would avoid all these useless conversions
of dates. What do you think ? Seems that lazy conversion made for the json
should stay the exception, not the general way to handle data types.
---
** [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:** Tue Aug 18, 2020 09:42 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
