Community
Participate
Working Groups
Build 3.0RC1 I was trying to bench Eclipse builds on a profiler. However, given it slew down my machine significantly, then intermediate notifications occur ever couple seconds, which means every 3 to 4 generated .class files. The process is then deadly slow. Moreover, to be resilient with slower machines we should have a greater delay for intermediate notifications. Maybe a time based solution isn't good enough, it should also take into account the amount of modified resources ? It doesn't matter on a slow machine I need progress every 2 seconds when you take twice as long in the end due to overhelming notifications.
The metric for intermediate notification frequency is: Math.max(1500, lastNotifyDuration * 10); In other words, either 1.5 seconds, or ten times the duration of the last notification. The idea is that on a slow machine, if notification takes longer, it will cause subsequent notifications to run less frequently. It is likely that the default delay of 1500 is too small for slower machines - this should probably be made a bit larger.
I did some quick tests in RC2. I would need a slower machine to find out if there is much difference. On a 2Ghz machine the intermediate notifications are almost trivial in duration. Here is output of all the notifications when doing a full workspace clean + build of core runtime + resources + OSGi. These numbers are just the difference of System.currentTimeMillis() from before and after notification. I know this generally doesn't detect differences of 10ms or less (they get reported as zero): Last notify: 0 Last notify: 94 Last notify: 0 Last notify: 0 Last notify: 16 Last notify: 0 Last notify: 0 Last notify: 0 Last notify: 0 Last notify: 16 Last notify: 15 Last notify: 16 Last notify: 0 Last notify: 0 Last notify: 0 Last notify: 0 Last notify: 0
Closing. There is no evidence that notifications are slowing down real user scenarios.
