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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format