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
speed.
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.
Glen
