xml-xalan-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28082] - XMLReaderManager provides neither no way to clear its cache nor it clears its cache by itself
Date Mon, 26 Apr 2004 19:11:01 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28082>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28082

XMLReaderManager provides neither no way to clear its cache nor it clears its cache by itself





------- Additional Comments From aseidl@myst-technology.com  2004-04-26 19:11 -------
As implemented, the XMLReaderManager only improves performance of
threads that use multiple XMLReaders.  This is because the XMLReader
instances are not shared across multiple threads.  Further, if such a
thread creates more than one reader at a time, only the most recently
created reader available for possible reuse.

I may be missing something, but it seems to make more sense to share
XMLReader instances across threads, much the same way a database
connection pool shares database connections across threads.  Maybe.  It
might make more sense to not cache readers at all.

How much of a performance bottleneck is created by not reusing XMLReader
instances?  How expensive is reader creation compared to the cost of
managing the reader cache?

One problem I've noticed is that XMLReader readers often maintain
references to objects representing the parsed document.  When such a reader
is returned to the cache of unused readers, it carries with it the
previously parsed document.  If this document is large, the memory
cost of caching the reader is large.  In an application such as a server
with hundreds of processor threads performing transformations, it can
result in significant memory costs to maintain the reader cache.

It may make more sense to create an _optional_ mechanism for reader
pooling that can be used in circumstances where it is really needed; and
not used where it would create undesirable memory costs or where it
would offer little performance improvement.

---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org


Mime
View raw message