Summary: | [Commands] performance: CommandsPerformanceTest#testBindingCacheHit*() regression | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Michael Van Meekeren <michaelvanmeekeren> |
Component: | UI | Assignee: | Douglas Pollock <douglas.pollock> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | P2 | Keywords: | performance |
Version: | 3.2 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Michael Van Meekeren
2005-11-14 09:55:45 EST
same for testBindingCacheHitSoft() I did a CVS diff, and there were no code changes in org.eclipse.core.commands or org.eclipse.jface during this time period. I also checked org.eclipse.ui.tests, and there were several minor changes related to other tests -- nothing that could clearly affect this test. I also checked org.eclipse.ui.workbench for collateral effects; there are none. The editor tests run before the command tests, and they open Java editors. The command tests are memory intensive. An initial guess is that there is a memory leak in some editor. I just talked with Kim Moir. No changes were made to the build scripts during that time. These numbers are, in general, higher than they should be (both 3.1 and 3.2). Looking further, there is a clear bug in TriggerSequence.hashCode -- introduced on February 25, 2005. I've fixed that problem. Still not happy with the results, I looked at ways to improve performance. I found a case where I can improve performance when the context tree is large. I've fixed that case. I'll also put in some piddling improvements to a couple of equals methods. I still have no idea why it spiked on August 18, 2005. But, with these improvements, it shouldn't matter. Closing as FIXED, to verify during 3.2 M4 milestone week. |