Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 482577

Summary:

[patch] Investigate Manifest editor for performance issues in large manifest files.

Product:

[Eclipse Project] PDE

Reporter:

Vikas Chandra <Vikas.Chandra>

Component:

Assignee:

PDE-UI-Inbox <pde-ui-inbox>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

curtis.windatt.public, Curtis_Windatt

Version:

4.6

Target Milestone:

4.6 M6

Hardware:

OS:

Windows 7

Whiteboard:

Bug Depends on:

Bug Blocks:

482576

Attachments:

Description	Flags
Fix1	none
Fix2	none

Description Vikas Chandra

2015-11-19 06:04:42 EST

Sometimes manifest files open quite slow especially when it has more contents.
This bug is created to investigate any performance improvement.

Comment 1 Vikas Chandra

2015-11-30 03:26:59 EST

Created attachment 258350 [details]
Fix1

Comment 2 Vikas Chandra

2015-11-30 03:27:24 EST

Created attachment 258351 [details]
Fix2

Comment 3 Vikas Chandra

2015-11-30 03:31:59 EST

I investigated the performance issues in manifest editor. The only place that can possibly be improved is the time taken for source page ( as per yourkit snapshot).

In fix1, I have scheduled a job to load the source pages and at the end of job completion, I have put setActivePage. So if the previous tab is the manifest tab, the editor will open 1st, the source tabs including manifest tab will be created and then the selection will switch to manifest tab. For all other tabs except the source tab, the switch will not happen.


In fix2, I have checked that if the previous selection was source tab, I dont create a job for creating the source pages. If the selection is any other tab, then the manifest file will seem to open early and the source pages will be created in another job.

Comment 4 Vikas Chandra

2015-11-30 03:47:36 EST

Curtis, do you think any of the approach mentioned in previous comment will help?

Comment 5 Curtis Windatt

2015-11-30 12:38:27 EST

Personally I've never had an issue with the manifest editor opening time.  If there is a significant delay affecting users, putting the work into a separate UI Job does allow the editor to open faster.  Of course UI Jobs would prevent the user from making any changes in the editor, so a better fix would be to move work out of the UI thread.

Comment 6 Vikas Chandra

2015-12-17 03:59:36 EST

Getting these kinds of error in Error Reporter of PDE.


UI freeze in PDEFormEditor.createPages - PDESourcePage.<init> (3.3s)

Status Message:
UI freeze of 3.3s at 11:20:23.242
Problem Trace:
org.eclipse.ui.FreezeWarning: UI freeze of 3.3s at 11:20:23.242
at org.eclipse.pde.internal.ui.editor.PDESourcePage.<init>(:-1)
at org.eclipse.pde.internal.ui.editor.PDEProjectionSourcePage.<init>(:-1)
at org.eclipse.pde.internal.ui.editor.KeyValueSourcePage.<init>(:-1)
at org.eclipse.pde.internal.ui.editor.plugin.BundleSourcePage.<init>(:-1)
at org.eclipse.pde.internal.ui.editor.plugin.ManifestEditor.createSourcePage(:-1)
at org.eclipse.pde.internal.ui.editor.MultiSourceEditor.addSourcePage(:-1)

Comment 7 Vikas Chandra

2016-03-04 04:47:24 EST

No significant part of the manifest file opening can be run in non-UI thread. So I dont see a scope in performance improvement.