Sam,
Doing work on a Job definitely makes like easier for the main thread, so
it's definitely a good option. The advantage of IStartup is that it
happens after the IDE is painted so that approach has zero impact
because it 100% offloads the work... But if no one can use it, because
it might be disabled, it seems crippled. In terms of the concern about
users disabling IStartup, I wonder who actually knows how to do that?
I.e., is this more a theoretical problem as opposed to a significant
problem?
On 17/12/2015 6:56 PM, Sam Davis wrote:
On Tue, Dec 15, 2015 at 11:22 PM, Mickael Istria <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
