Bug 189474 - [implementation] closing editors very slow
Summary: [implementation] closing editors very slow
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: 3.4 M5   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on: 128956
Blocks:
  Show dependency tree
 
Reported: 2007-05-28 12:50 EDT by Jeff McAffer CLA
Modified: 2007-12-20 12:11 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff McAffer CLA 2007-05-28 12:50:00 EDT
In rc1...

I happened to open a 1.6Mb XML document by dragging it from the windows desktop.  It opened quite quickly. I did notice quite some time of the CPU at 100%.  That appeared to be in the spell checker but I am not sure.  In any event, I let the CPU stablize.

Then I closed the file and it took approximatly 30 seconds to close.  During this time Eclipse was unresponsive and the CPU on my T42 was pegged at 100% by Eclipse.

I happened to be debugging that Eclipse and was able to get the following stack trace during the shutdown.  Note that this is in the Main thread!  All of the other threads appear to be uninteresting


Thread [main] (Suspended)	
	SynchronizableDocument(AbstractDocument).removePosition(String, Position) line: 1003	
	SynchronizableDocument.removePosition(String, Position) line: 203	
	SynchronizableDocument(AbstractDocument).removePosition(Position) line: 1015	
	AntExternalAnnotationModel(AnnotationModel).removePosition(IDocument, Position) line: 330	
	AntExternalAnnotationModel(AnnotationModel).disconnect(IDocument) line: 398	
	FileStoreTextFileBuffer.disconnected() line: 381	
	FileStoreTextFileBuffer(FileStoreFileBuffer).disconnect() line: 96	
	ResourceTextFileBufferManager(TextFileBufferManager).disconnectFileStore(IFileStore, IProgressMonitor) line: 219	
	TextFileDocumentProvider.disposeFileInfo(Object, TextFileDocumentProvider$FileInfo) line: 687	
	TextFileDocumentProvider.disconnect(Object) line: 642	
	TextEditor(AbstractTextEditor).disposeDocumentProvider() line: 4215	
	TextEditor(AbstractDecoratedTextEditor).disposeDocumentProvider() line: 1207	
	TextEditor(AbstractTextEditor).dispose() line: 4119	
	TextEditor(AbstractDecoratedTextEditor).dispose() line: 313	
	TextEditor.dispose() line: 92	
	EditorReference(WorkbenchPartReference).doDisposePart() line: 720	
	EditorReference.doDisposePart() line: 306	
	EditorReference(WorkbenchPartReference).dispose() line: 671	
	WorkbenchPage.disposePart(WorkbenchPartReference) line: 1585	
	WorkbenchPage.handleDeferredEvents() line: 1344	
	WorkbenchPage.deferUpdates(boolean) line: 1328	
	WorkbenchPage.closeEditors(IEditorReference[], boolean) line: 1302	
	WorkbenchPage.closeEditor(IEditorReference, boolean) line: 1357	
	EditorPane.doHide() line: 61	
	EditorStack(PartStack).close(IPresentablePart) line: 542	
	EditorStack.close(IPresentablePart[]) line: 206	
	PartStack$1.close(IPresentablePart[]) line: 121	
	TabbedStackPresentation$1.handleEvent(TabFolderEvent) line: 81	
	DefaultTabFolder(AbstractTabFolder).fireEvent(TabFolderEvent) line: 267	
	DefaultTabFolder(AbstractTabFolder).fireEvent(int, AbstractTabItem) line: 276	
	DefaultTabFolder.access$1(DefaultTabFolder, int, AbstractTabItem) line: 1	
	DefaultTabFolder$1.closeButtonPressed(CTabItem) line: 67	
	PaneFolder.notifyCloseListeners(CTabItem) line: 596	
	PaneFolder$3.close(CTabFolderEvent) line: 189	
	CTabFolder.onMouse(Event) line: 2149	
	CTabFolder$1.handleEvent(Event) line: 320	
	EventTable.sendEvent(Event) line: 66	
	CTabFolder(Widget).sendEvent(Event) line: 938	
	Display.runDeferredEvents() line: 3673	
	Display.readAndDispatch() line: 3284	
	Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2365	
	Workbench.runUI() line: 2329	
	Workbench.access$4(Workbench) line: 2204	
	Workbench$4.run() line: 466	
	Realm.runWithDefault(Realm, Runnable) line: 289	
	Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 461	
	PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149	
	IDEApplication.start(IApplicationContext) line: 106	
	EclipseAppHandle.run(Object) line: 153	
	EclipseAppLauncher.runApplication(Object) line: 106	
	EclipseAppLauncher.start(Object) line: 76	
	EclipseStarter.run(Object) line: 363	
	EclipseStarter.run(String[], Runnable) line: 176	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 64	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 615	
	Main.invokeFramework(String[], URL[]) line: 497	
	Main.basicRun(String[]) line: 436	
	Main.run(String[]) line: 1162	
	Main.main(String[]) line: 1137
Comment 1 Dani Megert CLA 2007-05-29 06:06:04 EDT
The annotation model doesn't know whether the document is still in use and hence removes all the annotations that it added to it. This is like that since day one but it is definitely not good, especially when there are tons of annotations like in this reported case.

Changing this at this stage is too dangerous and also needs new API where we can flag the document as about to be deleted.
Comment 2 Dani Megert CLA 2007-12-20 11:35:17 EST
Fixed in builds > N20071220-0010.
Comment 3 David Williams CLA 2007-12-20 12:04:58 EST
(In reply to comment #2)
> Fixed in builds > N20071220-0010.
> 

This sounds cool. Is there a new API "we" should know about? 

Thanks, 
Comment 4 Dani Megert CLA 2007-12-20 12:11:29 EST
There's no new API.

If you use file buffers you get it for free: the dispose method removes the position category before disconnecting the document from the annotation model.