Right now msm-javolution-serializer handles joda DateTime using reflection.
This results in rather verbose xml. It would save space if a more efficient
representation of joda datetime would be provided.
The heavy org.joda.time.chrono.ISOChronology is shared by several DateTime instances,
therefore the tons of xml for that would be serialized only once due to reference
handling.
As an alternative, I implemented a simple format/parse based serialization.
A short comparison shows both ways side by side: serialized a session with n DateTime
instances 1000 times, e.g. serializing a session with a single DateTime instance took
~900 msec using default (reflection based) serialization, and 260 msec using the
string format based serialization.
After tests are written I changed the implementation: now millis are stored, and
chronology and timezone if they are not default (default chronology is ISOChronology,
default timezone is chosen from DateTimeZone.getDefault()).
These chronologies are supported:
* ISOChronology
* CopticChronology
* EthiopicChronology
* GregorianChronology
* JulianChronology
* IslamicChronology
* BuddhistChronology
* GJChronology
After these changes I ran the performance comparison again, with just DateTime
instances created with "new DateTime()" - this choses ISOChronology and the default
timezone. New numbers:
Created new subproject javolution-serializer-jodatime, this provides the msm-
javolution-serializer-jodatime jar which must be placed in WEB-INF/lib, the Manager
element in server.xml/context.xml has to be configured with
customConverter="de.javakaffee.web.msm.serializer.javolution.JodaDateTimeFormat"
From martin.grotzke on January 05, 2010 08:57:40
Right now msm-javolution-serializer handles joda DateTime using reflection. This results in rather verbose xml. It would save space if a more efficient representation of joda datetime would be provided.
Right the xml for joda DateTime looks like this:
<_date class="org.joda.time.DateTime" __id="23" iMillis="1262297099473">From martin.grotzke on January 06, 2010 14:32:50
The heavy org.joda.time.chrono.ISOChronology is shared by several DateTime instances, therefore the tons of xml for that would be serialized only once due to reference handling.
As an alternative, I implemented a simple format/parse based serialization.
A short comparison shows both ways side by side: serialized a session with n DateTime instances 1000 times, e.g. serializing a session with a single DateTime instance took ~900 msec using default (reflection based) serialization, and 260 msec using the string format based serialization.
0x: 100 msec, 332 bytes 1x: 900 (260) msec, 10801 (480) bytes 2x: 900 (320) msec, 10997 (616) bytes 5x: 900 (520) msec, 11585 (1026) bytes 10x: 960 (640) msec, 12566 (1716) bytes 100x: 1391 (1200) msec, 30417 (14328) bytes
From martin.grotzke on February 08, 2010 18:04:01
After tests are written I changed the implementation: now millis are stored, and chronology and timezone if they are not default (default chronology is ISOChronology, default timezone is chosen from DateTimeZone.getDefault()).
These chronologies are supported: * ISOChronology * CopticChronology * EthiopicChronology * GregorianChronology * JulianChronology * IslamicChronology * BuddhistChronology * GJChronology
After these changes I ran the performance comparison again, with just DateTime instances created with "new DateTime()" - this choses ISOChronology and the default timezone. New numbers:
0xjoda : 100 msec, 332 bytes 1xjoda : 900 (180) msec, 10801 (467) bytes 2xjoda : 900 (200) msec, 10997 (590) bytes 5xjoda : 900 (340) msec, 11585 (961) bytes 10xjoda : 960 (520) msec, 12566 (1586) bytes 100xjoda : 1391 (860) msec, 30417 (13028) bytes
From martin.grotzke on February 08, 2010 18:12:12
Created new subproject javolution-serializer-jodatime, this provides the msm- javolution-serializer-jodatime jar which must be placed in WEB-INF/lib, the Manager element in server.xml/context.xml has to be configured with customConverter="de.javakaffee.web.msm.serializer.javolution.JodaDateTimeFormat"
Status: Fixed
Labels: FixedIn1.2
From martin.grotzke on March 20, 2010 14:58:48
(No comment was entered for this change.)
Labels: Milestone-1.2