[jdom-interest] Internal DTD subset verification

[Philip Nelson]

> 
> In other words, your tests deliberately do not include the cost of 
> I/O, which makes sense for what you're doing because I/O would 
> indeed swamp what you're trying to test. However, the fact is there's 
> not a huge amount of point to us optimizing input that's going to be 
> swamped by I/O in any real work scenario.

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.

One caveat though.  Awhile back I remember testing with MinML2 and saw that
most of the time during the parse was spent converting from byte to char (using
ibm profiling tools).  Could the use of a byte array be skewing the results
worse than reading from disk?

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com