Kirill,
The numbers I get using your method outlined below are actually still quite a bit different. So far I've benchmarked Sun's JAXB 2.0 reference implementation (from 9/19/05) and XMLBeans (v2), several times with the same results. One important change I made in the XMLBeans test is how marshalling is performed. Instead of creating a string out of the XML being marshalled and then serializing it, I use the save method on their base object like this:
((XmlObject)hierarchy).save(baos);
So the lower numbers I get (i.e. 6595kb versus 101238kb and 140ms versus 25864ms) would be explained by this. Would it be possible for you to make this change on your end?
To get the Level time number, I multiple the average time reported to System.out by the number of iterations (i.e. 1000 iterations for small, 100 for medium, and 10 for large data sets).
My setup is as follows:
JDK 1.5.0_03
Windows XP SP 2
Dell Lititude D600 with 1.86Ghz Intel Pentium M processor and 2GB RAM
JProfiler 4.0.9
Below are the results I get. Regards,
GIac
Marshaling
Time (ms)
Memory (kb)
Memory (objects)
Startup
Level
startup
level
startup
level
JAXB 2.0
Small data sets
6.2
122
7579
5349
89689
53041
Medium data sets
21
179
7740
15976
91132
133759
Large data sets
65
140
8239
6595
96118
63474
XMLBeans
Small data sets
39
223
378
31307
1920
51116
Medium data sets
144
273
629
11530
8561
13540
Large data sets
190
130
1501
3972
35008
34290
Unmarshaling
Time (ms)
Memory (kb)
Memory (objects)
Startup
Level
startup
level
startup
level
JAXB 2.0
Small data sets
30
444
7666
21544
90632
304302
Medium data sets
89
910
7776
9173
93847
297514
Large data sets
190
472
8074
3955
105195
144299
XMLBeans
Small data sets
397
272
6003
5920
34980
73811
Medium data sets
438
1545
6338
34363
36365
138438
Large data sets
441
390
8474
24954
41552
64875
Kirill Grouchnikov <kirillcool_at_yahoo.com> wrote:
Giac,
About feeding the data from JProfiler back to the
application. I have a long-term goal of using Kohsuke's
kprofiler library to do this. However, currently i'm busy
with other stuff, so it won't be done in the next months.
By the way, what degree of "closeness" are we speaking
about?
About time - you are correct. Multiply the time by the
number of iterations.
Kirill
--- JAXB User wrote:
> Kirill,
>
> Thanks for the explanation. I'm able to get very close
> to your results now. It is fairly labor intensive,
> though. If the data from JProfiler (saved as XML) could
> be fed back into your program, that would save a lot of
> time.
>
> For the time calculations, can I just use the avg. time
> numbers that you print out after a run? Would I just
> multiply the avg. time by the number of iterations run to
> get the level measurement?
>
> Regards,
>
> Giac
>
> Kirill Grouchnikov wrote:
> Giac,
>
> I'm sending this to the whole JAXB users list so that it
> will appear in the archive for the future reference.
>
> I am using JProfiler 3.2, and as i'm not familiar with
> JProfiler 4.1 GUI, you will have to find the
> corresponding
> options that match the attached screenshots by your own.
> But the main approach is the same.
>
> There are a couple of things that need to be clarified:
>
> 1. There's a lot more than marshalling / unmarshalling by
> a
> particular library, so you will need to drill down to the
> invocation of the library in order to get the exact
> results. For example, before marshalling, the object
> hierarchy needs to be allocated (and the memory for that
> is
> not taken into the account). In addition, after the
> object
> is marshalled, there's optional output which is also
> ignored in the results. These two specific functions are
>
org.jvnet.bindmark.benchmark.test.Jaxb2Test.createHierarchy
> and
>
org.jvnet.bindmark.benchmark.marshal.Jaxb2Marshaller.outputFinal
> in the first-marshalling.png and level-marshalling.png
> attached. Note that the real marshalling that is done in
>
org.jvnet.bindmark.benchmark.marshal.Jaxb2Marshaller.marshal
> calls com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal
> and is the real function that is profiled.
>
> 2. Every marshalling is done in its own thread (for
> checking multi-thread safety and performance). When the
> corresponding library allows, the constructor of this
> thread performs one-time activity (initializing the
> library), and the "real" marshaling / unmarshalling reuse
> the same thread-local object. The first-marshalling.png
> shows the allocation of JAXBContext object under the
> constructor of
> org.jvnet.bindmark.benchmark.marshal.Jaxb2Marshaller. As
> you can see, this happens in the action listener of the
> corresponding button in the GUI.
>
> 3. You must set "Live and garbage collected objects"
> option
> on the particular memory view in JProfiler to get the
> correct count of memory and objects during the
> processing.
>
> 4. The first-time marshalling involves both the
> constructor
> (first-onetime.png) footprint and the marshalling itself
> (first-marshalling.png).
>
> 5. The level marshalling footprint is
> level-marshalling.png
> numbers minus first-marshalling.png numbers.
>
> When you run the GUI, choose "1" iterations for the
> first-time and "10" iterations for the level.
>
> If you have any questions (the procedure is rather
> elaborate in order to get the exact footprint of the
> library and not the benchmarking overhead), you are
> welcome
> to ask.
>
> Regards
> Kirill
>
>
> --- JAXB User wrote:
>
> > Hi Kirill,
> >
> > I've downloaded your bindmark tests on my computer and
> am
> > attempting to reproduce the results. I'm having a hard
> > time figuring out how you arrived at the memory usage
> > numbers. Would it be possible to get more explicit
> > directions on how to measure these using JProfiler? I'm
> > using the latest version, JProfiler 4.1 beta.
> >
> > Once I've configured JProfiler to run the CheckGui
> > application, here's the procedure I'm currently
> > following:
> >
> > 1) Use the Memory views section, I chose the Recorded
> > objects tab and start recording.
> > 2) Go back to the CheckGui application and run one of
> the
> > tests (for example, the JAXB 2.0 Large Data Set test
> with
> > the default options).
> > 3) Go back to JProfiler and export the Recorded objects
> > view as a CVS into Excel.
> > 4) In Excel, sum up all of the object allocations
> > (instance count and size of objects).
> >
> > The numbers I get are very different than what you get.
>
> > For example, after 10 iterations of the large data set
> > test for JAXB 2.0, I get 181496 instances taking up
> 22835
> > kb, while you get 6595 instance taking up 63474 kb.
> I've
> > also tried using the All objects tab instead of the
> > Recorded objects tab, but still am not able to come
> close
> > to matching your results.
> >
> > Do you filter any instances from the count? How do you
> > take into account the awt objects from your GUI?
> >
> > Any help would be greatly appreciated! Thanks,
> >
> > Giac
> >
> >
> >
> > Kirill Grouchnikov wrote:
> > Hi,
> >
> > The last evaluation of JAXB 2.0 RI was back in April
> (on
> > its first EA), and it's been a long way since then. You
> > are
> > welcome to see [1] for the latest results (and great
> > improvements on marshalling speeds and memory
> > footprints).
> >
> > Regards
> > Kirill
> >
> > [1]
> >
>
https://bindmark.dev.java.net/servlets/NewsItemView?newsItemID=2572
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection
> > around
> > http://mail.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > users-unsubscribe_at_jaxb.dev.java.net
> > For additional commands, e-mail:
> > users-help_at_jaxb.dev.java.net
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection
> > around
> > http://mail.yahoo.com
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection
> around
> http://mail.yahoo.com
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail:
> users-help_at_jaxb.dev.java.net
>
> ---------------------------------
> Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief
> effort.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.