[jdom-interest] Internal DTD subset verification

[John Muhlestein]

I would like to add my vote for correctness over performance.  The primary
use case for my company is to use XML to provide web services.  The time it
takes to parse a document, in my experience, is insignificant compared to
the time it takes to perform an internet based transaction.  It is critical
that well-formedness and validation be consistent and correct since the I
don't have any control over the incoming source file.  As a secondary note,
I want to agree with Dennis' comment on the need for a stable API.  Again,
this seems to be more critical than tweaking the performance of JDOM.

2 cents worth from an average user.


> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo at metalab.unc.edu]
> Sent: Thursday, May 09, 2002 10:09 AM
> To: Philip Nelson; Dennis Sosnoski
> Cc: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Internal DTD subset verification
> 
> 
> At 8:03 AM -0700 5/9/02, Philip Nelson wrote:
> 
> 
> >In building systems where you are trying to maximize the number of 
> >simultaneous
> >users, this is not completely true, or false.  A slow IO 
> time will mean that
> >more documents will be loaded in memory at any point in time. 
> >Depending on how
> >much memory you have and how many users you need to support, 
> this is a bad
> >thing but there are ways to deal with it, add memory/swap 
> space etc..  On the
> >other hand, high IO time means that the cpu is free to do 
> other more important
> >things like service additional requests, increasing the 
> number of simultaneous
> >users.  A good thing.  Since cpu is much more difficult to 
> manage than memory,
> >I prefer to know that IO was not considered in the tests.  
> Also, in my
> >experience, with all recent hardware, disk access is 
> amazingly fast.  Just
> >compare time copying a file to parsing the same file.
> >
> 
> Let's make sure we're not comparing apples to oranges here. My claim 
> is that any real world application that uses JDOM is going to spend 
> so much time doing I/O, that document building time is insignificant. 
> If you're trying to measure document build time exclusively, then you 
> rightfully will try to eliminate the cost of I/O. However, the 
> resulting benchmark really won't prove that we gain anything 
> significant by optimizing document build time. If we reduce document 
> build time to zero, I/O will still cost. We can't easily do anything 
> about that. My claim is that the cost of I/O+SAX parsing is such that 
> compromising correctness is not an acceptable trade-off for reducing 
> JDOM tree construction time.
> 
> Also, please keep in mind, that although file access is an important 
> and real-world use-case so is network access, and that's going to be 
> even slower, often on the order of seconds. For instance, some of 
> Dennis Sosnoski's tests are SOAP documents. In the real world these 
> would almost certainly be served over a network connection. Even on 
> the fastest LANs, the sheer overhead of setting up a single TCP/IP 
> connection is likely to outweigh all other factors involved in 
> document building.
> -- 
> 
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
> |             http://www.cafeconleche.org/books/bible2/              |
> |   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
> |  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr at yourhost.com