Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Startup performance / Lazy creation of editors.

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





Back to the top