Re: XSL performance problem

Nicolas Pottier <nic@xxxxxxxxxx> wrote:
>Using String classes will get you extremely slow performance, as they're
>not designed to be used that way.  Without looking at your code I don't
>know for sure, but I would suspect you're doing alot of String
>concatenations etc, which you should use a StringBuffer for instead.


In our case the big hit was taking a "piece of the input" and looking it up
in a Hashtable. Using StringBuffer does not really help for the parser
side - it does help a bit on the output side.

>Using String objects will definetely get you in trouble
>performance-wise.


Right. There's a small issue of interfaces such as SAX being defined in
terms of the built-in String class, which inherently limits the amount of
tricks you can use. If at least there was an "intern" call that accepted a
character array as an argument... Sun has a bad record of missing features
like that. Well, let us hope the inherent inefficiency of SAX won't harm XSL
processors too much. Parsing is, after all, just a small part of what they
do.

>Server side Java should be plenty fast for pretty much anything, I
>recently ported some very CPU intensive code over to Java from optimized
>C++ and Java turned out about twice as slow, which isn't bad.


We actually had cases where we (almost) matched the C++ code speed - as long
as we were very careful about reusing instead of creating/releasing objects
(inside loops etc.). Java isn't inherently slow, it just encourages a
"create and forget" type of programming which is.

Have fun,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list