[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-ui-dev] Startup performance / Lazy creation of editors.
|
Just a
thought... perhaps the EditorPart implementations could be made into a
proxy/smart reference? This would allow all EditorParts to be loaded at
startup with minimal expense, and do the rest of the loading only when details
are used.
This
would require determining the basic metadata about EditorParts (which would be
directly available when the proxies are reloaded) and only load the details
(the plugin-specific implementation of EditorParts, the content, etc) if/when
needed.
--
Scott
Does anyone
*really* believe that restoring 50 editors is a useful thing to do? Restore
the ones which were visible when it shut down plus any others which were dirty
and throw the rest away.
McQ.
| Jared Burns
<jared-eclipse@xxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx
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