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.editor.indent.IndentImpl.reformatLock: LowPerformance took 37119 ms. | ||
---|---|---|---|
Product: | php | Reporter: | Exceptions Reporter <exceptions_reporter> |
Component: | Project | Assignee: | Tomas Mysik <tmysik> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | eduardoelias, mfukala |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 7.3 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 199253 |
Attachments: | nps snapshot |
Description
Exceptions Reporter
2013-03-04 11:30:23 UTC
Created attachment 132145 [details]
nps snapshot
Couple of attached profiler snapshots that I've checked, show AWT EDT (inside GsfReformatTask) waiting for the parser lock which is held by slow HTML indexing. *** Bug 230176 has been marked as a duplicate of this bug. *** In the few randomly chosen snapshots from 7.3 build I always see the PhpProjectUtils.reformatFile() being run from php new file wizard in EDT. Such operation IMO should not run in EDT as Dusan pointed out - the reformat lock tries to obtain parser lock which may be blocked by scanning. Not sure why dusan thinks html indexing is slow, but nevermind... Reassigning to project. *** This bug has been marked as a duplicate of bug 230985 *** |