Joern Huxhorn skrev:
Well, a stream could contain both LoggingEvent0916 and
LoggingEvent0918 and the Deserializer would produce the correct output
using instanceof and some defined conversion. The point is that the
old class would not be lost as it is the case if just the
serialVersionUID is changed. It could therefore still be deserialized.
After thinking it over I believe that this is the exact reason why
XMLEncoder/XMLDecoder was introduced in the first place - the ability to
read in old classes.
I don't think that it is possible to get to work _well_ but I'm always
happy for a good discussion.
Have you had the time to check my xml format? While it's not
exactly terse ;) it's definitely human-readable.
I think I have understood what the problem with my use of the
"humanly readable" term is. It is not the actual XML with names
and tags, but the data carried I am talking about. Timestamps are
fine but is not really readable to a human.
I can easily live with one character tag and attribute names if the
data in the fields carry meaning to the human eye :)
Well, I'm using yyyy-MM-dd'T'HH:mm:ss.SSSZ as the primary time stamp
format and then apply some magic to change it into a valid xml
timestamp, i.e. I add a colon between hh and mm of the timezone.
It mad my sigh quite a bit when I realized that SimpleDateFormat did
not support this...
A valid xml timestamp? According to what dialect? SOAP? Frankly I
think that these date objects are expensive to reconstruct - perhaps
you should look into this if performance is an issue to you? I
believe the date object just serializes the long datestamp which is
much cheaper to deserialize than to deconstruct a string into pieces
and build a date/calendar object from it. Note you also need
timestamp information for this so it most likely goes through a
Calendar.
Point taken, I wasn't really thinking about that when I was
implementing it, I primarily wanted to do it *right* ;)
It's an xs:dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime) which
seemed reasonable to me.
xs:dateTime expects a colon between timezone hh and mm while
SimpleDateFormat does only support hhmm :p
I implemented your suggestion and it's - unsurprisingly -
deserializing quite a bit faster, now.
Hehe, if I read your tables correctly the
lilithXmlUncompressedDeserializer went from 1.974544 sec to 0.497055
sec, which is four times faster so "quite a bit" is quite a bit of an
understatement :)
Also the value is very close to the 0.493445 value for
serializationUncompressedDeserializer so it appears that the two
approaches have about the same runtime performance.
Now I just need to update the schema... and I really need to implement
an EventWrapper Serializer that's using my xml so I can use it as the
Lilith file format...! Performance and size is absolutely acceptable.
Now I just need to bully you into shortening all tags and attribute
names into one character and skip any namespace prefixes :) Then we
agree O:-)
I moved the benchmarks to
http://apps.sourceforge.net/trac/lilith/wiki/SerializationPerformance so
I don't have to change the closed bug all the time :p
You _could_ also just reopen the bug :)
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
