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 20130304-c0d6ca0014a8) VM: Java HotSpot(TM) Client VM, 23.7-b01, Java(TM) SE Runtime Environment, 1.7.0_15-b03 OS: Linux User Comments: jtulach: (Re)loading 2mb JS file should not freeze everything for 55s! javydreamercsw: Took way to long to show red badges in file. lordbyrad: I was using diff between two wersions of on large JavaScript file (~1,15 MB and ~25 500 lines). jtulach: Paste of new 2MB of javascript into existing 2MB javascript file while replacing the previous content Maximum slowness yet reported was 55136 ms, average is 25083
Created attachment 132520 [details] nps snapshot
41s of delay while trying to leave the editor for output window (after pressing Ctrl-4) does not seem to be well justified activity. According to UI responsibility guidelines such delay makes the problem at least P2.
1/ Historically, the fold hierarchy lock is somehow shared with the view hierarchy; so if the fold hierarchy is locked (e.g. for an update), the view hierarchy is locked as well and cannot rebuild the views. According to Mila, this is still needed, so view hierarchy (in non-EDT) will be blocked while folds are updated. It's a question whether the lock must be Mutex, or r/w lock could be used, since view hierarchy and other clients (e.g. sidebar, caret, ...) read while only a few clients actually write. 2/ while fold boundaries are computed in parsing thread, the actual fold update is replanned to EDT - this was done since Retouche; the history is not captured in hg repository, but the rumor is that when the update run in a non-EDT thread, the IDE locked up. It's worth trying to run in non-EDT thread as the view hierarchy and draw engine was heavily rewritten from that time. 3/ the reson why the fold update is SO slow is that FoldInfos are put into a HashMap (to quickly find a matching ona) and FoldInfo.hashCode returns a constant - which turns the Map into a LinkedList effectively. (1) cannot be eliminated, maybe we could discuss the type of lock. (3) was fixed as part of issue #226413; the update() algorithm is based on merging of two ordered lists rather than Map lookup. This part is fixed for the trunk version. (2) could be worth trying, although because (3) is supposedly fixed, moving the update off the EDT should not make a big difference.
(3) was fixed as part of issue #227776.