<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [jdom-interest] Internal DTD subset verification</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>> But the I/O is relevant to anybody using JDOM who is going to have </FONT>
<BR><FONT SIZE=2>> read in the files form somewhere, possibly disk, possibly a network. </FONT>
</P>
<P><FONT SIZE=2>I think that's Dennis' point. I/O is going to be an equal factor regardless of the source of the document. Your disk and network are going to perform as they will regardless of what API you are using. Using that as a measure of JDOM (or any other API) speed would invalidate what you are testing, i.e. build performance. </FONT></P>
<P><FONT SIZE=2>> My claim is that in that more realistic scenario, JDOM performance is </FONT>
<BR><FONT SIZE=2>> a much smaller fraction of the total. Thus we really shouldn't be </FONT>
<BR><FONT SIZE=2>> wasting out time optimizing it, and we certainly shouldn't be </FONT>
<BR><FONT SIZE=2>> worrying about optimizing it at the expense of correctness.</FONT>
</P>
<P><FONT SIZE=2>I agree. If runtime speed is that critical, most applications should be using something else to begin with. I'd much rather have it be right and not-as-fast-as-X than have it be faster-than-thou and not guarantee correctness.</FONT></P>
<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Jerome O'Neil</FONT>
<BR><FONT SIZE=2>Sr. Software Engineer</FONT>
<BR><FONT SIZE=2>The Cobalt Group</FONT>
<BR><FONT SIZE=2>206.219.8008</FONT>
</P>
</BODY>
</HTML>