[jdom-commits] CVS update: jdom/src/java/org/jdom/input

[cvs at jools.org]

Date:	Friday April 12, 2002 @ 10:00
Author:	cvs

Update of /home/cvspublic/jdom/src/java/org/jdom/input
In directory jools.org:/tmp/cvs-serv27593

Modified Files:
	SAXHandler.java 
Added Files:
	TextBuffer.java 
Log Message:
Patch from Alex Rosen.  In his words:

--
I tried some more tests using different buffering strategies. I tried 5 new
strategies, mostly with Xerces 1 and Crimson on JDK 1.2.2, but also some
with Xerces 2 and some with JDK 1.4. Basically, it doesn't much matter what
strategy you use, as long as you don't try to reuse the StringBuffer. (The
strategies included using a new StringBuffer each time, plus 4 variations on
the idea of putting the first chunk into a String, and the rest into either
a StringBuffer or an explicitly-managed char array.)

- The beta 8 version is fine, because it uses StringBuffer.substring(),
which creates a String that doesn't share the underlying char array. But,
it's not JDK 1.1 compatible.

- The current CVS version, which is 1.1 compatible, has horrible
performance. I'm not 100% sure why that is. At least part of it has to do
with the fact that it's creating a minimum 16-char array for each string.
That eats up memory quickly when a lot of the text sections consist of only
a newline, for example.

- All 5 of the schemes I used come out about the same, and are comparible in
speed to beta 8. The only noticable difference is that when you use a
StringBuffer, you can end up with extra, unused memory laying around
(because StringBuffer.toString() tries to use its internal buffer, which
might be bigger than necessary). Even with Crimson, this is only significant
in edge-case documents, where characters() gets called many times per text
section, but I guess it's worth fixing.

So I used a TextBuffer class that Brad sent me, which puts the first chunk
into a String, and then for subsequent chunks it uses its own char array
instead of using a StringBuffer. This should get us pretty optimal
performance, and remain 1.1 compatible. This class could be reused if we
have other builders in the future, e.g. XNIBuilder.

I also changed name of the internal subset StringBuffer from "buffer" to
"internalSubset", to avoid confusion.

Alex
--

In my own testing, under JDK 1.4 I don't see much difference before and
after this patch.  Sometimes it's faster, sometimes it's a little slower.
Under JDK 1.2.2 though this patch is a fantastic speedup, nearly cutting
in half the build times!  

Interestingly, after this patch I see some builds are faster under 
JDK 1.2.2 (JIT) than JDK 1.4 (HotSpot).  Ah, the joys of performance 
tuning Java...

-jh-

===================================================================
File: no file TextBuffer.java		Status: Needs Checkout

   Working revision:	1.1	Fri Apr 12 14:00:34 2002
   Repository revision:	1.1	/home/cvspublic/jdom/src/java/org/jdom/input/TextBuffer.java,v

   Existing Tags:
	No Tags Exist

===================================================================
File: no file SAXHandler.java		Status: Needs Checkout

   Working revision:	1.43	Fri Apr 12 14:00:34 2002
   Repository revision:	1.43	/home/cvspublic/jdom/src/java/org/jdom/input/SAXHandler.java,v

   Existing Tags:
	jdom_1_0_b8              	(revision: 1.39)
	jdom_1_0_b8_rc1          	(revision: 1.38)
	jdom_prefilter           	(revision: 1.27)
	jdom_1_0_b7              	(revision: 1.18)