Re: [platform-ui-dev] Startup performance / Lazy creation of editors.

[Jared Burns <jared-eclipse@xxxxxxxxx>]

I'm using an internal method to cycle editors. Since my view is being 
contributed to the platform, I'll be able to access whatever internal methods 
the UI uses to get the list of editors. But my gut tells me that I should be 
able to make this view in a seperate plugin. Being able to get the list of 
open editors doesn't feel like something that only the UI plugin should be 
able to do.

I'm curious as to how this change yields a performance increase. Are you 
still going to show tabs for all of the previously open editors when the 
workbench is restored? If so, doesn't that already require most (all?) of the 
API on IEditorInput? You still need to get the editor's name and image (which 
requires the plugin, right?) to show the tabs.

I can understand wanting to lazily initialize the editors. We definitely 
shouldn't be reading the contents of non-visible editors and creating widgets 
for them, for instance. But that doesn't seem at all related to the workbench 
page answering IEditorInputs. If a file editor input doesn't initialize the 
file until someone asks for it, where's the cost? I'm sure I'm missing 
something here (I know approximately zilch about the implementation), but it 
seems that the performance enhancement will come from changes to the editor 
input implementations, not the workbench page.

- Jared

On Tuesday 30 April 2002 04:46 pm, you wrote:
> I think you are already using internal methods to be able to implement
> your view, are you? As I remember your view was supposed to be part of the
> platform. I this case you will be able to fix it by calling a few internal
> methods. I am still thinking if these methods should became API or not. We
> have a lot of actions that depend on getEditors as well. CTRL+F6 for
> example.
>
> It is a trade-off we are analyzing: is it better to not have this
> functionality or change it in order to get better performance on startup?
>
> We are trying to avoid activating plugins by not creating editors and
> views.
>
> Eduardo.
>
>
>
>
>
> 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
>
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-ui-dev