Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: Using the resources API, set the content of a large XML file (about 2MB) while the XML editor is open. Observe poor performance as a result of the DOMModelImpl.nodesReplaced receiving an event with over 100K nodes replaced. For me Eclipse hangs for about 10 seconds while I'm waiting for processing to complete. In this case the entire contents of the document was replaced. Wouldn't it make more sense to call nodesReplaced with the root node of the document? More information: To figure out this one I paused the debugger while running a self-hosted eclipse session. Stack trace from debugger. Daemon Thread [Thread-2] (Suspended) Character.digit(int, int) line: 4531 Character.digit(char, int) line: 4490 Integer.parseInt(String, int) line: 454 DocumentImpl.getCharValue(String) line: 612 TextImpl.getData(IStructuredDocumentRegion) line: 260 TextImpl.getData(IStructuredDocumentRegion) line: 240 TextImpl.getData() line: 222 TextImpl(CharacterDataImpl).getNodeValue() line: 150 XMLModelNotifierImpl.valueChanged(Node) line: 484 DOMModelImpl.valueChanged(Node) line: 906 TextImpl(NodeImpl).notifyValueChanged() line: 627 XMLModelParser.removeStructuredDocumentRegion(IStructuredDocumentRegion) line: 2205 XMLModelParser.replaceStructuredDocumentRegions(IStructuredDocumentRegionList, IStructuredDocumentRegionList) line: 2338 DOMModelImpl.nodesReplaced(StructuredDocumentRegionsReplacedEvent) line: 671 JobSafeStructuredDocument(BasicStructuredDocument)._fireEvent(Object[], StructuredDocumentRegionsReplacedEvent) line: 602 JobSafeStructuredDocument(BasicStructuredDocument).fireStructuredDocumentEvent(StructuredDocumentRegionsReplacedEvent) line: 1200 JobSafeStructuredDocument(BasicStructuredDocument).internalReplaceText(Object, int, int, String, boolean) line: 1979 JobSafeStructuredDocument(BasicStructuredDocument).replaceText(Object, int, int, String, boolean, long) line: 2414 JobSafeStructuredDocument(BasicStructuredDocument).set(String, long) line: 2930 ResourceTextFileBuffer.handleFileContentChanged(boolean, boolean) line: 513 ResourceFileBuffer$2.execute() line: 151 ResourceFileBuffer$2(ResourceFileBuffer$SafeFileChange).run() line: 86 UISynchronizationContext.run(Runnable) line: 34 ResourceTextFileBufferManager(TextFileBufferManager).execute(Runnable, boolean) line: 607 ResourceFileBuffer$FileSynchronizer.resourceChanged(IResourceChangeEvent) line: 179 NotificationManager$2.run() line: 288 SafeRunner.run(ISafeRunnable) line: 37 NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 282 NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148 Workspace.broadcastPostChange() line: 313 Workspace.endOperation(ISchedulingRule, boolean, IProgressMonitor) line: 1022 File.setContents(InputStream, int, IProgressMonitor) line: 374 File.setContents(InputStream, boolean, boolean, IProgressMonitor) line: 469
I forgot to mention: this is also causing a memory issue. See attached heap dump analysis
Created attachment 108911 [details] heap analysis
Created attachment 109203 [details] a plug-in that has a single JUnit to exercise the problem Added a JUnit test that can exercise the problem. To run the JUnit, run Eclipse with the attached plug-in self-hosted (the attachment is an Eclipse plug-in project). You should see the main menu with 'Bug 242802 Test' added. Invoke the menu item contained within the menu, and wait for a pop-up. The assertion should fail and a pop-up informs you that the file contents took > 1000 millis to execute. On my mac it takes at least 4s, sometimes more than 5s.
Created attachment 109204 [details] mylyn/context/zip
Created attachment 109332 [details] memory profiled using visualgc see annotations in image: 1. test started 2. editor opened 3. file contents replaced
Created attachment 109337 [details] profiling results 1
Created attachment 109338 [details] profiling results 2
Created attachment 109370 [details] heap dump showing excess memory usage
Created attachment 109371 [details] dominator tree from heap dump showing major offender
Created attachment 109374 [details] leak hunter report Seems to be a memory issue.
Attached some screenshots of profiling results. Note that the file.setContents() portion of the test takes aproximately 50% of the profiled time. I was wrong about my initial assumption: the DOMModelImpl.nodesReplaced() part of the operation is responsible for about 16% of the CPU time, the other 60% from StructuredPresentationReconciler.processRecordedDamages()
while the profiling shows hot spots in the code, it could be that it's taking so long due to excessive heap utilization. In cases such as this, garbage collection can take > 80% of CPU time.
If memory serves me correctly some fixes have gone into WTP 3.2 to address this issue, but Nick maybe you remember better then myself because I also think it was you who put them in.
(In reply to comment #13) > If memory serves me correctly some fixes have gone into WTP 3.2 to address this > issue, but Nick maybe you remember better then myself because I also think it > was you who put them in. Unfortunately, I'm seeing roughly the same results as David when I run his unit test (which is much appreciated!). We've had some memory improvements and other performance defects but they didn't seem to affect this area of your report.
*** Bug 143088 has been marked as a duplicate of this bug. ***
*** Bug 422368 has been marked as a duplicate of this bug. ***
*** Bug 136935 has been marked as a duplicate of this bug. ***
Is it still not possible to fix? Started : 2008-07-31 19:28 EDT Pleeeeease!...
