Andreas L. Delmelle wrote:

-----Original Message-----
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]

Committers, I don't see a problem with what Nils proposes. Does anyone
else? If not, I can do the change next week. If Nils already has a patch
for us, even better. :-)

Well, the whole idea behind using interned strings and the == operator is
As you both are probably well aware, using .equals() on interned strings is
a lot slower than comparing them with ==.

Not necessarily--I suspect implementations of .equals() probably first check if they == each other, and if so quickly return true before trying a character-by-character compare.

You do have a point here though--this portion of the code is heavily activated. What I don't understand is why this problem hasn't happened before. If I run command-line, or even embedded, the String for the namespaceURI normally ends up being shared with the static FO_URI String created earlier. It's probably a poor programming practice to rely on that fact, but I still wonder why Nils' namespaceURI <> FOP's FO_URI here.

It may affect 'only' 30 types, but of these types, many can have an
unlimited number of instances or children --think of fo:block/fo:inline...--
so this means that such comparisons could be made hundreds (maybe even
thousands) of times.

Another option: validateChildNode() is called from only one place, FOTreeBuilder.startElement(). At that point, we can also feed vcN() the parameter "namespaceURI.intern()" instead of just "namespaceURI". This could be slightly faster for some VCN()'s that compare against multiple URI's--but I would think .intern() is much slower than .equals() for the reason given above.


Reply via email to