Community
Participate
Working Groups
I20080613-2000 Given JOGL OpenGL SWT snipped from here http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet209.java?view=co 1. Paste to new project 2. Add SWT to the Build path 3. Add JOGL to the BP (https://jogl.dev.java.net/servlets/ProjectDocumentList?folderID=9260&expandFolder=9260&folderID=0) 4. On line 99 type 'gl.gl', ctrl-space, 'C' Is: very fast, good 5. Add Javadoc for JOGL to jogl library (https://jogl.dev.java.net/servlets/ProjectDocumentList?folderID=9260&expandFolder=9260&folderID=0) 6. On line 99 type 'gl.gl', ctrl-space, 'C' Is: Once the content assist popup is up, Eclipse is not responding for about 40 (sic!) seconds, on every keystroke, and to make it worse: the popup shell stays on top of every other application window. Should: Maybe it's acceptable the first time, but subsequents calls must be fast This is major, if not critical, I had to remove Javadoc, which makes it very difficult to program against this library. 'GL' is a C wrapper class containing around 4700 members. Yes, this is a lot but might happen in such an setup, plus JOGL is a quite common used library. This is also in 3.3.2 Not sure if this is JDT/Texts or JDT/Cores fault: "main" prio=6 tid=0x00038d20 nid=0x1690 runnable [0x0007e000..0x0007fc3c] at java.lang.String.indexOf(String.java:1597) at java.lang.String.indexOf(String.java:1564) at java.lang.String.indexOf(String.java:1546) at org.eclipse.jdt.internal.core.BinaryMethod.extractJavadoc(BinaryMethod.java:625) at org.eclipse.jdt.internal.core.BinaryMethod.getParameterNames(BinaryMethod.java:252) at org.eclipse.jdt.internal.codeassist.InternalCompletionProposal.findMethodParameterNames(InternalCompletionProposal.java:120) at org.eclipse.jdt.core.CompletionProposal.findParameterNames(CompletionProposal.java:1950) at org.eclipse.jdt.ui.text.java.CompletionProposalLabelProvider.appendUnboundedParameterList(CompletionProposalLabelProvider.java:106) at org.eclipse.jdt.ui.text.java.CompletionProposalLabelProvider.createMethodProposalLabel(CompletionProposalLabelProvider.java:265) at org.eclipse.jdt.ui.text.java.CompletionProposalLabelProvider.createStyledLabel(CompletionProposalLabelProvider.java:536) at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.computeDisplayString(LazyJavaCompletionProposal.java:245) at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.getDisplayString(LazyJavaCompletionProposal.java:230) at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.isValidPrefix(AbstractJavaCompletionProposal.java:709) at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.isValidPrefix(LazyJavaCompletionProposal.java:349) at org.eclipse.jdt.internal.ui.text.java.JavaMethodCompletionProposal.isValidPrefix(JavaMethodCompletionProposal.java:236) at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.validate(AbstractJavaCompletionProposal.java:672) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals(CompletionProposalPopup.java:1455) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$4(CompletionProposalPopup.java:1418) at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run(CompletionProposalPopup.java:369) I can send you the project in question if you want to, I'm not sure if I'm allowed to attach it here.
Can reproduce using 3.4 RC4. Not a regression (same since at least 3.2). NOTE: On platforms where no virtual table is available, we already see the blocked UI on first code assist because the labels need to be computed for all elements in the table. On the reported platform (WindowsXP) the virtual table is available and hence only when filtering the first time we need to compute all the labels. The time is spent in BinaryMethod.extractJavadoc(IType, String) and there in code where String.indexOf(String, int) is called (esp. line 625). Possible fix could be to run once through the javadoc string which is cached and store the start positions.
Created attachment 105028 [details] Profiler data
I could probably add a workaround for the virtual table case but there's nothing I can do for the non-virtual table case as I do need all the labels. Some background data: the proposal list contains 4731 proposals/entries.
Created attachment 105876 [details] First proposal With this patch the ranges of all children of the declaring type are computed at the same time to avoid to call 'indexOf' from the start of the javadoc for each methods and fields. The test case of comment 0 take 2 seconds instead of 40 seconds. This patch is only a draft and can be slightly improved.
Changing target milestone to 3.5 since: - this is not a regression (comparing to at least 3.2) - the change is simple (risk of introducing a regression in a maintenance release) - even if much better, the performance is still not acceptable (2s is too long for code assist)
*** Bug 263156 has been marked as a duplicate of this bug. ***
Created attachment 127647 [details] Proposed fix When extracting the javadoc of an element the range of this javadoc is stored to be reused later and the positions of all the previous html anchor are stored. These positions will be used to extract the javadoc of the other elements. This data are stored inside the 'javadocCache' of 'PerProjectInfo'. With this patch the test case of comment 0 take between 1 and 2 seconds instead of 35 seconds. It is not perfect but it is better than 35 seconds.
Released for 3.5M6.
Verified for 3.5M6 using I20090310-0100.
