[jdom-interest] JDOM Performance

[Alex Rosen]

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.

Alex

>>> Mike Brenner <mikeb at mitre.org> 6/6/2003 12:13:12 PM >>>
Kevin wrote:
>         http://www.sosnoski.com/opensrc/xmlbench/index.html 
> It compares Java XML processing models for DOM, JDOM, DOM4J and a
number of
> XML api's. It compares performance in terms of memory utilization,
parsing
> 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
benchmark,
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
list
was to replace 
	
	return myStringBuffer.toString();

with 

	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
like:
	- string-to-number parsers with defaults
	- printf
	- pixel length of a string given the font
	- html/xml/sql/unix/dos/etc. encodings for special characters
and quotings
	- 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:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com