[jdom-interest] Suggestions for increasing speed of JDOM based app
arosen at silverstream.com
Tue Feb 26 11:06:52 PST 2002
Excellent recommendation. Another thing to try, if you have fixed or at
least repeating searches, is using a compiler for XSLT and/or regexp, which
builds a special-purpose class file for performing the tranformation and or
search. Xalan has XSLTC, I'm sure there's some regexp compiler somewhere.
It sounds like you're using some not-too-speedy technologies (XML, XSL,
regexp) for an app that needs a lot of performance, which may be the root of
your problem. I don't know anything about what you're trying to do, but can
you do something else instead, like store the info in a database?
> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Dennis Sosnoski
> Sent: Tuesday, February 26, 2002 1:38 PM
> To: Simon McLeish
> Cc: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Suggestions for increasing speed of JDOM
> based app
> Actually I should clarify this - if you're using an Iterator to go
> through the list there should not be a problem with the beta
> 7 code; if
> you're using indexing to go through the list then there definitely is.
> Your problem is more likely to be with the regex and/or XSLT
> though. If you want to check this just disable the regex
> matching (have
> your matching code always return "false") and see how fast
> your app runs
> without either of these steps. Then enable the regex matching
> but skip
> the XSLT output generation, so that you get separate measurements for
> each of these.
> Assuming these are the problem areas, you can (1) try to get better
> matching code (perhaps you don't need full regex, for
> instance) or use
> it more efficiently (make sure you're not rebuilding the patterns for
> each match, etc.), and (2) build the output directly rather
> than using XSLT.
> I've not been impressed by the machine-specific compilers for Java.
> Modern JVMs get performance reasonably close to what the
> machine-specific ones can achieve, without any of the hassle. You're
> better off looking for algorithm improvements, as discussed above.
> - Dennis
> Dennis Sosnoski wrote:
> > Beta 7 has a known performance problem in that it uses linked lists
> > for returned lists. If you're iterating through a long list of
> > children the time required is O(n^2).
> > I think this has changed in the current CVS version, so you
> if you've
> > been using beta 7 you might want to try your program with
> the current
> > CVS code before investigating further.
> > - Dennis
> > Simon McLeish wrote:
> >> Hi,
> >> I've recently developed an application which uses JDOM
> heavily - it
> >> traverses an XML document, matches a search string against certain
> >> text nodes using java.util.regex, and performs an XSL
> >> to display the hit count in a hierarchy matching the original
> >> document. Unfortunately, this turns out to be quite slow as far as
> >> users are concerned (in some documents, there are
> thousands of nodes
> >> to check and a threaded search across all 30 of them takes
> about 70
> >> seconds depending on the complexity of the search query), and I
> >> wondered if anyone has any suggestions which might help
> speed it up.
> >> One option I've considered is using an ahead of time compiler to
> >> create a machine-specific binary, and any reports on
> experience with
> >> this. (Looking at the gcj home page makes me think that
> it's unlikely
> >> to be possible to do this for an app that uses JDOM, however.)
> >> I'm assuming that people are likely to want to send
> generic responses
> >> rather than wade through the code, but if anyone wants to do that
> >> I'll happily send it to them.
> >> TIA,
> >> Simon
> >> _______________________________________________
> >> To control your jdom-interest membership:
> To control your jdom-interest membership:
To control your jdom-interest membership:
More information about the jdom-interest