Community
Participate
Working Groups
When opening Eclipse against medium (or big) workspaces (mine has 120 projects), the Java Tooling initialization task takes a non negligeable amount of time, and is CPU consuming. This, for example, prevents user from performing an Open Type once Eclipse has been launched, until this task is completed. Main of the time seems to be spent while reading index files... This also can be reproduced using 3.3 milestones.
Philippe, is it ok to target this bug to 3.2.2?
Created attachment 57501 [details] Proposed fix This optimization significantly reduces the CPU time used to read index files. I'll post real measurements ASAP, in order to evaluate the effective gain.
Candidate for 3.2.2 since fix is trivial and provides significant improvement on startup times.
Created attachment 57504 [details] Yourkit performance comparison Attached is a screen shot in which the CPU times are compared: note that the CPU time for Util::readUTf(DataInput) is divided by 6 with the proposed fix applied.
Created attachment 57505 [details] Alternate patch on top HEAD Alternate possible solution regarding the readUTF issue. Faster (regarding CPU time) than the 1st patch.
(In reply to comment #2) > Created an attachment (id=57501) [details] > Proposed fix > > This optimization significantly reduces the CPU time used to read index files. > I'll post real measurements ASAP, in order to evaluate the effective gain. > This fix has been released for 3.2.2 in R3_2_maintenance stream. I keep the bug opened it will be also put in HEAD stream (see comment 5)...
Change target as final fix was not really put in 3.2.2 stream...
Created attachment 59356 [details] Ultimate patch to optimize read and write UTF operations
Performance tests on this patch results with a gain around 12% for searchAllTypeNames test. Note new specific written test shows a gain around 23% on a searchAllTypeNames request when index category table are not cached.
(In reply to comment #8) > Created an attachment (id=59356) [details] > Ultimate patch to optimize read and write UTF operations > Released for 3.3 M6 in HEAD stream. Closing for now as FIXED, I reopen it and change the target when I'll release corresponding change in R3_2_maintenance stream...
*** Bug 150837 has been marked as a duplicate of this bug. ***
Verified for 3.3 M6 using build I20070320-0010
Is it OK to backport this fix on R3_2_maintenance stream?
For now, please just prepare the patch against R3_2_maintenance. We will decide later if this needs to be released to R3_2_maintenance
Created attachment 62230 [details] Corresponding patch for R3_2_maintenance branch Note that this patch has been done on top of R3_2_maintenance branch which as this time, and for the concerned modified classes, should be equivalent to version v_686_R32x... Note also that this patch includes fix for bug 138309.
Patch released in Startup_R32x branch
(In reply to comment #15) > Created an attachment (id=62230) [details] > Corresponding patch for R3_3_maintenance branch > > Note that this patch has been done on top of R3_2_maintenance branch which as > this time, and for the concerned modified classes, should be equivalent to > version v_686_R32x... > > Note also that this patch includes fix for bug 138309. > It looks like this patch also includes the fix for bug 174971. Frederic can you please confirm ?
(In reply to comment #17) > It looks like this patch also includes the fix for bug 174971. Frederic can you > please confirm ? > Yes, I confirm it also includes fix for bug 174791. I didn't precise it as this bug fixed a regression introduced by bug 171653 fix...
