[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|