Adding a few links and other info -
Aleksander Slominski wrote:
http://dev2dev.bea.com/articles/hitesh_seth.jsp that is
good overview but has not enough technical details and
other docs): as far as i can understand actual objects
Above you've linked to an XML Journal review reprint.
Here is a page the points to other information:
http://dev2dev.bea.com/technologies/xmlbeans/index.jsp
One of the links is a very brief summary of some
brutally transparent and upfront performance and
test compliance numbers:
http://workshop.bea.com/xmlbeans/schemaandperf.jsp
BTW, despite the fact that we posted the numbers on
pretty marketing pages on bea.com, the numbers above
are not marketing-varnished numbers - they are the
actual measurements that we developers track day-to-day.
Those are numbers we measure to help us focus on
use-cases that we're working on making faster.
The XML cursor access _without_ strong-type conversion is
between 10% and 58% faster than Xerces2 DOM access, going
to about 35% for large (1Mb) XML documents. Xerces2, btw,
is extremely speedy, so we're proud to be on par with it
in any scenario!
Adding strong-type conversion (for example parsing xs:int
to java int and dates to Calendars) adds enough cost that
reading the data out of a document is between 0% and 48%
slower than reading out using (untyped) Xerces2 DOM.
Apples-to-apples, we measure ourselves significantly
faster than JAXB RI and Castor (140% to 282% and 66% to
800%). Please don't sue me - those are our real numbers,
but if performance is important to your application,
you should measure it for yourself.
We do fault-in object allocations when demanded, and
you can see in our memory test that when we fault-in
all the objects for a whole document, we take up more
memory than Xerces2 DOM. One current project is to take
steps to reduce that number. When we use XmlCursor and
don't fault-in all the objects, the memory number you
will find to be much slimmer. (I don't have a measurement
because our measurements focus on problem areas we're
actually working on.)
Eric Vasilik writes:
The synchronization described refers to the fact
that one may manipulate the XML via the XmlCursor
or the strongly typed XMLBean classes generated from
the schema
As Eric says, we don't want to confuse the two uses of
the word synchronize. But since Aleksander brought it
up - here's some information on thread-synchronization
too.
We examined both with- and without-thread-synchronized
access, and found that without-thread-sync, programmers
fall into traps like working with XML config files on
multiple threads in thread-unsafe ways without without
being aware of it. We found that it costs between 1%
(strongly-typed access) and 10% (XmlCursor access) to
synchronize. So we're currently synchronizing access
to the data now, paying for more [app] stability with a
little bit of perf. We'd like to provide the option to
single-threaded (or savvy) users of not synchronizing
to get the 1-10% back. That's future work.
As Eric pointed out, the key I think is not in what our
current numbers are, but the fact that we've isolated
our implementation from our interface so that we have
the flexibility of reducing allocations, deferring work,
and otherwise improving performance further in the future.
Abstracting the primary store behind a cursor rather
than a tree of objects with identity gives us some leeway
in shuffling our implementation strategy in the future
without restructing the APIs.
David Bau
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
