Re: [cross-project-issues-dev] Improve Startup Performance ofEclipse

[Ed Merks]

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 > 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 > 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


___
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

Re: [cross-project-issues-dev] Improve Startup Performance ofEclipse

[Sam Davis]

On Tue, Dec 15, 2015 at 11:22 PM, Mickael Istria  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  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

Re: [cross-project-issues-dev] Improve Startup Performance ofEclipse

[Mickael Istria]

On 12/16/2015 12:01 AM, Sam Davis wrote:

because the user can disable them
That's kind to give the power to the user, but in the end, put yourself 
into an Eclipse IDE user shoes: Are users aware that long startups can 
be configured by them? Will they be able to find the right UI entry to 
tweak the startup? If they manage to get to the list of startups, will 
they easily identify which ones are necessary for them or not, or 
time-consuming?
None of these operations is trivial enough for users to expect them to 
take care of it.
It's a recurrent issue in Eclipse IDE, for many many operations and 
options: how are users supposed to *discover* them? If there is nothing 
driving user to them, it's more or less the same as not having them.


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?

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat 
My blog  - My Tweets 

___
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