Re: XSL performance problem

Subject: Re: XSL performance problem
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Wed, 19 May 1999 10:33:35 +0200
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

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

>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:

Current Thread