[jdom-interest] Suggestions for increasing speed of JDOM based app

[Dennis Sosnoski]

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 processing, 
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 transformation 
>> 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:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com 
>>
>>
>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com 
>
>