Community
Participate
Working Groups
In WTP we use CompletionProposalCollector to convert Java proposals to JSP proposals. When calling CompetionProposal#getAdditionalProposalInfo() (in LazyJavaCompletionProposal), it looks like an HTTP connection is being opened for each proposal. This slows our content assist tremendously, and blocks the UI while collecting (and converting our proposals from Java > JSP, ~10 second hang) I tracked it down to JavadocContentAccess#getHTMLContentReader(...): In the case for our JSP proposals the content reader is null, so the "useAttachedJavadoc" block is called, which opens eventually opens the URL connection. It looks like it's because member.getClassFile() in this case returns null. In the case of a regular Java file, a content reader is return, apparently because member.getClassFile() actually returns a class file, and there's a buffer to read. Here is the related WTP bug to reproduce the problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=124483 Let me know if I can provide more info.
It depends whether there's source (attached) or not. If no source is attached it tries to get it from attached Javadoc. Which Eclipse build are you using? JDT Core improved the performance in that area. Also note that clients can set the timeout for getting the Javadoc from attached Javadoc, see Preference > Java > Content Assist > Work in Progress.
WTP 1.5 still builds with eclipse 3.2M4 I can try a more recent build to see if the performance is better.
Please also give the preference a try. We could adapt the default if necessary.
I tried I20060208-0848 and the performance is still very slow. Adjusting the timeout preference didn't seem to have an effect. I couldn't see anywhere in the code path were the preference was being used... I see that JavaElement#getURLContents() tries to create an input stream each time, maybe this is part of the bottleneck? If I no-op that method the time goes from ~18 seconds to ~6 seconds. Still slow but about 1/3 the time.
>I couldn't see anywhere in the code path were the preference was being used... Should be used in JDT Core code.
Just on a side-note - computing additional info will often be slow (javadoc extraction, html formatting...) and doing it for every proposal is not something you want to do if you have hundreds of proposals. How about wrapping the proposals and only lazily computing the additional information upon request?
(In reply to comment #4) > Adjusting the timeout preference didn't seem to have an effect. > I couldn't see anywhere in the code path were the preference was being used... AFAIK, the timeout only affects the retrieval of parameter names of methods, but not of the entire javadoc. Retrieving javadoc for every proposal upfront will never perform. You should definitely try to delay this call.
Tom's correct: the preference is only used on J Core side when they resolve the parameter names upon completion proposal computation. In addition there's also bug 129168 on Platform Text side.
As you suggested, wrapping a Java proposal w/ our JSP proposal and calculating getAdditionalInfo() only when required fixes the problem (and makes more sense than calcuating everything up front). This one can probably be closed since we can fix from our end.
=> close as WONTFIX
See ICompletionProposalExtension5 (>= R3.2).
