From: "Dane Foster" <[EMAIL PROTECTED]>
> I have a hard time agreeing with the argument of increased performance
using
> an XML to Java binding mechanism over an API that provides generic access
to
> any XML data source. Any increases in performance gets foreshadowed by
the
> increase in complexity required to apply/maintain the bindings. I'm
> generally never pro or con against any idea.
I tend to agree. Mapping xml to Java objects is not trivial. Working with
XML via XPath and XSLT is pretty easy, straightforward and very powerful.
I'm increasingly coming to the conclusion that XML is often a better form to
keep "data" in than Java Beans - even if they are code generated. Its so
easy to navigate, process and reformat XML whereas Java Beans require custom
coding to navigate & reformat.
> I strive to stand in the
> middle of everything and evaluate everything based upon the environment
and
> the requirements for that particular environment. That said, in the XML
> space, real-time communication is the only environment that I know about
> that would require the speed gains "implied" by XML -> Java bindings. So
if
> real time is what you are doing then XML is not the data format you want
to
> use because XML carries overhead that a real-time system should be
avoiding.
Agreed.
Premature optimisation is the route of all evil as the man once said.
I'd rather get the software I'm writing finished earlier then add more
business benefit or tune the entire application as a whole than worry too
much about a possible 10% or so gain in XML parsing performance up front.
Often developers optimise the wrong thing anyway (myself included).
Optimisation should only be done after sufficient profiling of the entire
application highlights a certain area as requiring optimisation.
On a related note, its often considered that XML is 'slow' because its text
based and that Java Object Serialization is 'fast' because its binary.
Whenever I've tried some head-to-head comparisons of fairly complex object
graph serializations versus the same structure as an easy to read XML
document, I've often found working with XML to actually be faster and
smaller than serialization. Also XML lends itself very well to be GZipped to
be even smaller 'on the wire' if need be.
> But if you are using generic XML and are some kind of speed freak, dom4j
> (and other APIs) provide ways to turn up the juice. You can (in dom4j):
> 1) Write your own tree implementation
> and/or
> 2) Use your own SAXContentHandler to make a custom built Document that
> contain only the nodes that your application requires while ignoring the
> rest.
You could also use an XMLFilter with the existing SAXReader in dom4j to do
more filtering or preprocessing (such as normalizing all text, CDATA and
entities together into a single Text node or filtering unwanted parts of the
tree and so on).
> Anyway, I've wasted enough of everyone's time with my opinions. Have a
good
> one
I like hearing other peoples opinions on such matters! ;-)
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
