Castor Mapped,Unmrs mn,7,85,94,Unmrs av,18,97,112,Mrshl mn,3,47,37,Mrshl av,7,51,44
Castor Mapped,Unmrs mn,10,151,128,Unmrs av,21,170,142,Mrshl mn,4,78,52,Mrshl av,14,81,55
Castor Generated,Unmrs mn,7,83,102,Unmrs av,26,100,128,Mrshl mn,4,63,55,Mrshl av,12,64,64
Castor Generated,Unmrs mn,9,141,132,Unmrs av,27,160,153,Mrshl mn,5,95,67,Mrshl av,18,104,86
Here's 0.9.4 with the same system and test data:
Castor Mapped,Unmrs mn,13,127,119,Unmrs av,27,147,142,Mrshl mn,5,77,55,Mrshl av,14,81,63
Castor Mapped,Unmrs mn,15,229,165,Unmrs av,28,244,182,Mrshl mn,5,116,70,Mrshl av,25,124,75
Castor Generated,Unmrs mn,10,98,110,Unmrs av,25,117,138,Mrshl mn,4,71,60,Mrshl av,12,73,70
Castor Generated,Unmrs mn,9,187,153,Unmrs av,27,210,176,Mrshl mn,5,108,77,Mrshl av,23,115,90
I get the results running several timed passes over the same data, tracking the time for each pass. For comparison purposes I usually go by the best times ("Unmrs mn" for "unmarshal minimum time", "Mrshl mn" for "marshal minimum time") of the passes, since this should be representative of long-term JVM optimizations. I used Xerces 1 for both sets of tests - I've found Xerces2 offers much better performance for small files, but is actually slower for large files.
The two lines of each type ("Castor Mapped" and "Castor Generated") within a set of results show the effect of two different formats of the same XML data. In the first line the format makes heavy use of attributes; in the second it uses child elements with text content for the same data. The three numbers within each measurement give the times for, respectively, a small file used only for initialization (class loading and compilation, etc. - I don't consider this part of the actual test and ignore the result), a single large file (100-200KB), and a collection of smaller files (1-5KB).
I'm preparing an article for publication that includes some timing comparisons. The actual test code will be included with the article, but I should be able to distribute it to any of the developers who are interested in trying it out ahead of time - if we can find out why the performance has dropped (or in the - unlikely ;-) - event I've made an error!) I can incorporate the information in the article. Contact me directly if you'd like to get the test code early.
- Dennis
Arnaud Blandin wrote:
Hi Dennis,----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
I have no real clue of what could have happened to slow down that much
the performance, maybe some reference are not cleared during the
marshalling/unmarshalling process. We plan to do a profiling of Castor
once we are feature complete.
To optimize the performance, I advise you to use Xerces 2.Is there a
place where we can see the results of your test cases?
Arnaud
-----Original Message---------------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
From: Dennis Sosnoski [mailto:dms@;sosnoski.com]
Sent: Sunday, October 20, 2002 11:11 AM
To: [EMAIL PROTECTED]
Subject: [castor-dev] XML binding performance
I've run some timing tests for XML binding performance and was
surprised
to see that more recent versions are considerably slower than
0.9.3.9
(the earliest one I tested). In my tests 0.9.4 takes a minimum of
about
10% longer than 0.9.3.9 for marshalling and unmarshalling with code
generated from Schema, while for mapped bindings the difference is
more
like 20-30%. In the worst case (a couple of fairly large files,
100-200KB, using mapped bindings) 0.9.4 takes about 50% longer than
0.9.3.9. These times are using the Sun 1.4.1 JVM on Linux (1.3.1
shows
about the same differences, though mapped binding performance is
considerably slower overall on 1.3.1 - probably because of the
reflection optimizations in 1.4).
I'd noticed this at least as far back as 0.9.3.21 (I didn't try
anything
in between 0.9.3.9 and 0.9.3.21). About half the XML is mapped to
Strings, a quarter to ints and a quarter to object ids. Anyone have
an
clues why there'd be such a big drop in performance?
- Dennis
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
