Community
Participate
Working Groups
Based on some performance analysis work I've been doing for core, it looks like the UI-level progress monitor can cause far too many UI events. I think the culprit is jface.operation.AccumulatingProgressMonitor. For example, if I have an operation that has 10,000 units of work, and I call worked(1) 10,000 times, it may create 10,000 RunnableLock objects and do 10,000 asyncExecs to post them to the event queue, etc. At the UI level, the knowledge must be available of how many units of change can actually be presented to the user. By eye-balling it, it looks like there are only about 50 progress blocks in the indicator, which means only about 50 of those RunnableLocks and asyncExecs can actually be changing what the user sees. Shouldn't AccumulatingProgressMonitor buffer those worked() calls until a meaningfully representable increment has been reached, and then post something to the event queue? Local refresh is an extreme example, but worked() calls were taking about 12% of the entire operation. I wrote some simple code in core to do the buffering described above, and it reduced this to less than 1% of the total time. NOTES:
PRODUCT VERSION: Build 0.131
Defer
Reopen for investigation
Clients should not send progress updates at such a fine granularity. There are no plans for the UI team to work on this defect until higher priority items are addressed.
Marking WONTFIX
