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

[Eduardo_Pereira@xxxxxxx]

I think we can give you enough API to persist/restore the info you need. 

Thanks.
Eduardo.

Darin_Wright@xxxxxxx Sent by: platform-ui-dev-admin@xxxxxxxxxxx 04/30/2002 09:11 AM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-ui-dev] Startup performance / Lazy creation of editors.

The debugger's current editor re-use implementation will break the rules you are proposing. When the workspace is shutdown, the debugger remebers the editor it was using (i.e. the editor it opened), via an index into the list of open editors (i.e. integer offset). The next time the debugger needs to display source (after restarting the workspace), it accesses the edtior via #getEdtiors(). Is there some other way we could identify the editor that the debugger opened (and persist that information). 

Darin

Eduardo_Pereira@xxxxxxx Sent by: platform-ui-dev-admin@xxxxxxxxxxx 04/29/2002 04:21 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx        cc:                Subject:        [platform-ui-dev] Startup performance / Lazy creation of editors.

As part of the startup time improvement work, we are thinking about not creating editor that are not visible on startup. I.e. only one editor will be created at startup if the user has only one window with one editor workbook opened. Only the tabs will be created for the other editors. 

To be able to change this, we need to remove/add API related to editors. One of the biggest problem is the API IWorkbenchPage.getEditors() which returns an array with all IEditorPart(s) created in that page. 

This optimization would work only if all senders of getEditors were changed to use new provided API. 

The API getEditors would be deprecated and changed to restore all editors not restored by the time it was sent. API such as: findEditor(IEditorInput), getDirtyEditors(), would be added to IWorkbenchPage.  Another API that could/would be necessary is selectAndReview(ISelection) which would collect the parts  that implements ISetSelectionTarget and send selectReveal(ISelection) only to the parts already created. findEditor(IEditorInput) would instanciate the editor and return it. 

I took a look in all senders of getEditors (Platform and JDT) to check what they are using it for and if they  are running on startup. Most of the senders running on startup are part of platform UI which makes it easier for us to implement this proposal. However, all senders should be changed because the first one to send getEditors would create all the editors taking a long time. 

If the time permits we would like to do the same kind of change for views that are hidden in a tab folder. 

Comments are appreciated. Please let me know if findEditor(IEditorInput), getDirtyEditors(), selectAndReview(ISelection)  would not be 
enough to do the work that your senders of getEditors() are doing. 

Thanks. 
Eduardo.