Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] More parsing performance patches

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] More parsing performance patches
  • Date: Fri, 22 Jul 2005 12:14:58 -0700

On Jul 22, 2005, at 4:42 AM, Elliotte Harold wrote:

private static final String[] TABS;



Do you really need the carriage returns here? The XML parser is going to normalize all carriage returns and carriage return/ linefeed pairs in the input document to linefeeds when parsing. A carriage return is only gong to appear if the user has used a numeric character reference to specially insert a carriage return. That does happen but it's quite uncommon. I

It doesn't hurt to play it safe. Parser behaviour may unexpectedly change.


The basic idea looks good. Given that more than one call to characters per text, I wonder if we can simplify it somewhat. Suppose we ignored StringBuffers completely? In other words, if characters was called a second or third time we just append directly to the string? This would leave the code about as simple as it is now, maybe simpler; and still take the same path as your patch for the 99% case where characters() is only called once. The hit wouldn't even be too bad when characters() was called more than once, because it almost never would be called more than two or three times. (Aside from the very weird #3 where performance would be abysmal, but honestly that really requires an updated parser.)


Again, the idea is to play it safe, ensuring a performance desaster can never happen. With the variant you checked into CVS today a String0 + ... + StringN concatenation desaster would be possible. The algorithm is really not that difficult, and there's a reason it is formulated the way it is.

Wolfgang.




Archive powered by MHonArc 2.6.24.

Top of Page