Community
Participate
Working Groups
build 3.2 M3 This test has shot up in N20050818 and not come down, has the test changed OR code changed? It is slower on all platforms, but we need to explain why if it is not really a problem.
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.
