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.
Summary: | org.netbeans.modules.csl.editor.fold.GsfFoldManager$CommitFolds.run: LowPerformance took 55136 ms. | ||
---|---|---|---|
Product: | editor | Reporter: | Jaroslav Tulach <jtulach> |
Component: | CSL (API & infrastructure) | Assignee: | Svata Dedic <sdedic> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | javydreamercsw, jtulach, lordbyrad, mmetelka, sdedic |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 7.4 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 193725 |
Bug Depends on: | 226413 | ||
Bug Blocks: | |||
Attachments: | nps snapshot |
Description
Jaroslav Tulach
2013-03-12 15:00:55 UTC
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. |