I did some benchmarks and here are the results: no date handling at all - 17 seconds josm-ng date conversion - 19.5 seconds josm-ng date conversion done with char[] instead of string - 18.8 seconds.
josm-ng version is 13% slower but that makes only 2.5 seconds on 80MB file. Also it allows more memory efficient storage of timestamp. I personally would get rid of lazy parsing parsing and use Petr's version. What do you think? On Mon, Mar 9, 2009 at 6:03 PM, Petr Nejedlý <[email protected]> wrote: > Jiri Klement napsal(a): >> >> Hi, >> >> Attached patch replaces timestamp and parsedTimestamp in OsmPrimitive >> with DateContainer class accessible only using setter and getter. The >> patch is not much usefull on itself but hopefully its the first step >> to make OsmPrimitive encalupsed (without public variables) so things >> like spatial index or better caching will be possible in future. >> > > I have read both the patch and the thread and I would suggest something > different, once you're > touching this and removing public access to the field(s). > First, adding another holder class is both unnecessary and a memory waste. > You can add reasonable > access methods directly to OsmPrimitive (while providing e.g. DateComparator > for comparing OsmPrimitive > dates, if necessary) and resort to keeping only a private integer timestamp > (in seconds, not long millis) > inside the OsmPrimitive. > This means that you'll need to parse all the timestamps during xml parsing, > but if done properly, > you won't notice the slowdown. Feel free to use the parsing code from > josm-ng: > http://svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/utils/DateUtils.java > which I do use quite quickly for datasets much larger that JOSM can even > imagine. > (I have spent quite some time benchmarking and optimizing the parsing code, > you can be sure > I know why there was lazy parsing and everything in the riginal code). > > As long as you hide the field and provide only the Date/String(/int) API, > you can reintroduce the String > field anytime though (but you won't need to). > > Regarding your: "// TODO Is it enough to compare string representation? > Dates can be in different format but are they in real life?" > No, it isn't. The timestamps seem to be stored in the OSM database in the > textual form or at least keep the original > timezone information (which is useless anyway) and you'll encounter many > different formats (timezones) coming from the OSM > server all the time (in the same download). Just download a random area, > store to a file and look there. > > Once you're all integerized, you can remove all the String based code paths > to simplify the code. > > Petr > > _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
