[josm-dev] [PATCH] timestamp & parsedTimestamp in OsmPrimitive

[Jiri Klement]

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ý <petr at nejedli.cz> 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
>
>