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 >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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL performance problem, Nicolas Pottier | Thread | Re: XSL performance problem, Oren Ben-Kiki |
RE: XML and ASP, Michael . Orr | Date | Re: XSL performance problem, Oren Ben-Kiki |
Month |