[jdom-interest] JDOM Performance
arosen at novell.com
Fri Jun 6 11:01:09 PDT 2003
The fix that we actually used to get around the StringBuffer memory
issue was a lot better than that - see org.jdom.input.TextBuffer. It
most cases it should use the minimum storage necessary for its strings.
So any extra memory usage would be coming from other parts of JDOM.
>>> Mike Brenner <mikeb at mitre.org> 6/6/2003 12:13:12 PM >>>
> It compares Java XML processing models for DOM, JDOM, DOM4J and a
> XML api's. It compares performance in terms of memory utilization,
> performance, etc. It's a great analysis.
> Only problem is it's a couple years old and discusses Jdom b7
After it is updated for 2003, and since JDOM is built upon a parser,
I guess we would not be concerned about the DOM and SAX numbers,
because they are parsers, not trees built upon parsers like JDOM is.
What is EXML? A web search shows that General Dynamics, Eiffel,
Electric XML, and possibly others have a product built on top
of an xml parser whose abbreviation is exml? Oh, I see where
the answer it -- it is Electric XML.
Since EXML is similar to JDOM (built upon a parser),
and because it was faster than JDOM at the time of the posted
perhaps that is the benchmark to compete against for performance?
> ... I suspect JDOM allocates too many temporary objects triggering
many GC runs. ...
But, to avoid the memory leakage in StringBuffer, it's not just JDOM
that has to
allocate many temporary objects. Since the JDOM solution posted on this
was to replace
return new String(myStringBuffer.toString());
we ourselves now have to allocate "too many" temporary objects also.
In addition to this memory leakage, I have learned that there is the
same problem when you use substring -- it does not make a copy, but
keeps the longer string around.
[ Why do so many languages mess up their implementations of variable
length strings, the most important data structure in software?
Perhaps someone could write a variable length string package that
has the kinds of methods that are in String and StringBuffer along
with the methods that always have to be added to it in every project
- string-to-number parsers with defaults
- pixel length of a string given the font
- html/xml/sql/unix/dos/etc. encodings for special characters
- dictionary (i.e. a HashMap of Strings indexed by Strings
requiring no casts)
- xml-ifying an array of strings or a HashMap of Strings, etc.
To control your jdom-interest membership:
More information about the jdom-interest