This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 236439

Summary:	org.openide.text.UndoRedoManager$DocLockedRun.<init>: LowPerformance took 24700 ms.
Product:	platform	Reporter:	pinbender
Component:	Text	Assignee:	Miloslav Metelka <mmetelka>
Status:	RESOLVED WONTFIX
Severity:	normal	CC:	alexvsimon, dalin, faximili, rocmxp, swilk, vgrigory
Priority:	P1	Keywords:	PERFORMANCE
Version:	7.4
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:	195290
Attachments:	nps snapshot nps snapshot

Description pinbender 2013-09-26 21:33:59 UTC

Build: NetBeans IDE Dev (Build nbms-and-javadoc-524-on-20130919)
VM: Java HotSpot(TM) Client VM, 23.25-b01, Java(TM) SE Runtime Environment, 1.7.0_25-b17
OS: Windows 7

User Comments:
pinbender: Reloading a largeish C++ file. (3800 lines)



Maximum slowness yet reported was 24700 ms, average is 14227

Comment 1 pinbender 2013-09-26 21:34:00 UTC

Created attachment 140522 [details]
nps snapshot

Comment 2 Exceptions Reporter 2013-11-08 12:33:12 UTC

Created attachment 141987 [details]
nps snapshot

switching between applications on windows 7

Comment 3 Miloslav Metelka 2013-11-12 10:11:36 UTC

The view updates lead to TextLayout creation which call
sun.font.SunLayoutEngine.nativeLayout[native]()	taking 14,201 ms for just 38 samples (AWT thread waits for a read lock on the reloaded document). I think I cannot improve the situation in this particular case.

Comment 4 Alexander Simon 2015-03-06 10:09:52 UTC

Please reevaluate issue because my report 768499 does not have "sun.font.SunLayoutEngine" problem.
P1 because 74 reports.

Comment 5 Miloslav Metelka 2015-09-09 08:40:34 UTC

The culprit of report 768499 is a slow filesystem spending 68277ms in org.netbeans.modules.remote.impl.fs.RemoteFileObject.refresh() calling
org.netbeans.modules.remote.impl.fs.RemoteDirectory.readEntries () and waiting in
org.netbeans.modules.remote.impl.fs.server.FSSResponse.getNextPackage ()

FO.refresh() is part of FS transaction that is invoked inside document's write lock and it would later read the file's content and insert it into the document.
AWT is blocked on the document's (being loaded) readlock.

Even if we would somehow eliminate the FO.refresh() the same issue would arise with reading from the file's stream very likely.
The only definite solution would be to completely split all the IO based stuff from the document's handling i.e. the document's write lock section would be entered with a String holding the file's content and a time when the file's was read.
A question is whether the compatibility requirements of the openide.text will allow such a change but we should probably at least give it a try.
Even more difficult will be handling of reload where a document is already loaded and editable.

I have filed a new issue #255122 with P2 priority (it's not a common situation to have so slow FS) for the next NB version to handle this rewrite.
I'm closing this issue to its original resolution.