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.
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
Created attachment 140522 [details] nps snapshot
Created attachment 141987 [details] nps snapshot switching between applications on windows 7
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.
Please reevaluate issue because my report 768499 does not have "sun.font.SunLayoutEngine" problem. P1 because 74 reports.
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.