[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Startup performance / Lazy creation of editors.
|
What about the active Perspective?
Perspectives like Debug should always be in their own window so that they
don't mess up the set of Editors you are working with. And since there is
no preference to ask the Debugger to open in its own window, I have to
leave it open all the time, including on shutdown. The user is probably
always in a Java Perspective too. So for me those two plugins will always
require startup. In WSAD, you can count on the default Perspective causing
90% of the load time.
For reuses threshold, I am not requesting a new feature, but suggesting
that the existing one is poorly defined. It treats Dirty and Clean editors
the same. Having it apply to only clean editors reduces Editor "bloat"
when you are just browsing code, but still lets you get your work done when
modifying code. I think most users agreee that if you could reduce the
default threshold without affecting how one works, that that would be a
good thing.
tchau,
Randy
|---------+--------------------------------->
| | Eduardo_Pereira@xxxxxx|
| | m |
| | Sent by: |
| | platform-ui-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 04/30/2002 05:54 PM |
| | Please respond to |
| | platform-ui-dev |
| | |
|---------+--------------------------------->
>------------------------------------------------------------------------------------------------------------|
| |
| To: platform-ui-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [platform-ui-dev] Startup performance / Lazy creation of editors. |
| |
| |
>------------------------------------------------------------------------------------------------------------|
It is not just a matter of how many editors you have opened but how many
plugins are going to be activated by those editors. For example you if
have plugin.xml, a .java file and a .txt file opened, we would not
activate PDE neither Java plugins if the .txt was the visible file.
You can set the editor threshold to one and if the editor is dirty it will
ask you if you want to save it of open a new one. If you want you can open
a feature request to have a YES ALL check button added to "always save or
always open a new editor".
Eduardo.
"Randy Hudson" <hudsonr@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
04/30/2002 05:32 PM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-ui-dev] Startup performance / Lazy
creation of editors.
The real problem is Editor bloat. Solve that problem first, then look at
performance. I never wanted all of those windows open to begin with, but
the weak editor management means I have to have set my "reuse threshold"
too high.
The "Number of Open Editors before closing" preference should only apply
to
*clean* editors. I personally would then set this number to ONE, and I
would have VA-Java++. The exception being that if the current Editor is
dirty, I can open up another Editor along with the first.
|---------+--------------------------------->
| | Jared Burns |
| | <jared-eclipse@xxxxx.c|
| | om> |
| | Sent by: |
| | platform-ui-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 04/30/2002 04:48 PM |
| | Please respond to |
| | platform-ui-dev |
| | |
|---------+--------------------------------->
>
------------------------------------------------------------------------------------------------------------|
| |
| To: platform-ui-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [platform-ui-dev] Startup performance / Lazy
creation of editors. |
| |
| |
>
------------------------------------------------------------------------------------------------------------|
It sounds like this will completely break my editor management view. The
view
displays the currently open editors as returned by
IWorkbenchPage.getEditors(). I don't see how I can find out which editors
are
open if the getEditors() API is removed.
It strikes me as a fundamentally bad idea for the Eclipse platform to not
provide access to the open editors. Maybe I'm missing something here, but
it
seems like we have a performance problem that we're just trying to avoid
by
removing functionality. The correct solution here should be to improve the
implementation of EditorPart and the code that restores the editors on
startup.
Why is it so expensive to restore a workbench with 50 editors open? Are we
opening them serially and processing each editor creation to the fullest?
Things like block operations and lazy initialization should solve this
problem - without having to eliminate API.
- Jared
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
