Community
Participate
Working Groups
This test consistently ran in the 7-8 second range up to and including build I20050104. It then made a drastic jump at I20050111 and now runs in the 11-12 second range. This consistent pattern suggests a real regression. Investigate.
The only change I can find is WorkerPool.java revision 1.46 added two calls to synchronized methods in WorkerPool.sleep(). This was to fix a serious bug caused by reentrant calls to Job.schedule (bug 82146). I'll investigate if this might be the cause, and see if there is anything that can be done about it. Note that the test case is to run a "no-op" workspace operation, so it's not out of the question that a small change could introduce a major regression. It's also not clear if this is a significant performance defect. If I run the test a thousand times, the average time per iteration is 0.02 milliseconds (with I20050329).
Note: 20 microseconds for a no-op isn't actually very good.
I examined all the changes in core and core test projects between these two builds, and found nothing relevant. Reverting the WorkerPool change described in comment #1 made no difference. Looking more closely at the test results, I see the regression is in wall-clock time, but the CPU time is not significantly different. It's possible that another background job running from a previous test is delaying this test from starting. The "no-op" operation grabs a lock on the workspace root, so any job running on the workspace would block it. I've made some changes to the test to run a single no-op operation, and then waiting for background autobuild, before starting the timer for the body of the test. This should eliminate the influence of any other background job on this test. I didn't touch the body of the test between the timer start and stop, so the results should be comparable to previous runs.
I wasn't able to find a performance problem here.
