On Tue, Dec 15, 2015 at 11:22 PM, Mickael Istria <mist...@redhat.com> wrote:
> > Why not scheduling a job inside the IStartup? So you get the best user > experience with faster startup, and still the possibility for advanced > users who actually tweak that kind of thing to enable/disable it? > The concern is that users who don't know what they are doing will disable things to "improve" performance and end up with a broken IDE. On Wed, Dec 16, 2015 at 2:00 AM, Ed Merks <ed.me...@gmail.com> wrote: > The disadvantage of scheduling a job in the startup, is that it's > processed during the time when the IDE itself is trying to paint for the > first time, whereas IStartup happens after the IDE is visible to the > user. So the former has the potential to impact the perceived startup > time while the latter happens after the user perceives their IDE is up and > running. > Hmm, on my machine it takes about 0.06ms to create and schedule a Job. So with 1200 plugins installed, if every single one of them started eagerly and scheduled a job, the total time spent scheduling jobs would be about 72ms, which is not perceptible. Of course these numbers are not worth the paper they're printed on, but nevertheless I think the time spent loading classes for the bundle's start() method is likely to be much greater than the time spent scheduling a job, so I'm not sure there is much gain to be had from using IStartup. Cheers, Sam
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
