[jdom-interest] Is beta-5 much slower than beta-4?

[Elliotte Rusty Harold]

At 4:32 PM -0700 10/18/00, Jason Hunter wrote:

>This reminds me of something I've been thinking about wrt performance.
>Elliotte wrote code that checks all text content to ensure it contains
>only legal XML characters.  We haven't included it yet because it causes
>a significant performance hit (maybe 10%).  What I'd really like is a
>way to configure if you want this checking on or off, but unfortunately
>that's very difficult without adding factories for all object creation,
>and I don't want to go there.
>

I've thought about this a lot. As you know I'm a fanatic about not 
letting anything malformed into the document. However, I totally 
agree that there's no need to do the check when an object is read by 
a parser that is also doing these checks. It's just pointless 
duplication of effort.

The natural way I see around the problem is to add some hidden 
functions to the various Element, Attribute, ProcessingInstruction, 
and other classes that do not make any checks but that could only be 
accessed by builders. In C++ you'd do this with friend functions, but 
Java doesn't have friend. We could do it with package private methods 
but the builder classes are in a different package.

Possible solution 1:

Move the builder classes into org.jdom. In fact ditch the package 
structure completely.  Put everything in org.jdom. When I was working 
on namespaces the output problem was significantly harder for the 
same sorts of reasons; i.e. I couldn't create friendly functions in 
Element that XMLOutputter could access.

Possible solution 2:

Create special subclasses of Element, ProcessingInstruction etc. in 
the org.jdom.input package. Give these package private methods that 
don't do the checks (as well as the normal public ones that do). Then 
use these subclasses for input rather than the standard versions. 
Does anyone see any obvious flaws with this approach?

The public interface to and behavior of these subclasses would be 
identical to the interfaces we have now. No client code would need to 
be changed. Thus we don't even have to do this optimization now. It 
can be rolled in at any convenient time, and I suggest waiting until 
the public API is stable and real tests prove it's necessary.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+