Summary: | Content assist does not scale with javadoc on type with many members | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Benno Baumgartner <benno.baumgartner> | ||||||||
Component: | Core | Assignee: | David Audel <david_audel> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | major | ||||||||||
Priority: | P3 | CC: | daniel_megert, jerome_lanneluc, Olivier_Thomann, philippe_mulet, toni00 | ||||||||
Version: | 3.4 | Keywords: | performance | ||||||||
Target Milestone: | 3.5 M6 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Benno Baumgartner
2008-06-16 05:01:12 EDT
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. |