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: | Formatting takes too long - holding document lock | ||
---|---|---|---|
Product: | javascript | Reporter: | tbrunhoff <tbrunhoff> |
Component: | Formatting & Indentation | Assignee: | Petr Hejl <phejl> |
Status: | RESOLVED INCOMPLETE | ||
Severity: | normal | CC: | adben, alesak, azizur, ccscoder, charlweed, crosati, davti, exceptions_reporter, igorrius, janario, jbecicka, jlueters, lzgrillo, mattmcla, nathury, Stevie69, szmitek, TobiasKranz, tomzi, velkymx, vsrikarunyan, zeloras |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 7.3 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 172014 |
Attachments: |
nps snapshot
nps snapshot Sample Javascript file |
Description
tbrunhoff
2010-08-18 17:59:17 UTC
Created attachment 101497 [details]
nps snapshot
Created attachment 101741 [details]
nps snapshot
Starting new build of NB with new User Dir.
*** Bug 188495 has been marked as a duplicate of this bug. *** slow native painting What is the solution for "slow native painting."? Is it a bad X server (currently vanilla fedora 12), my graphics card (NVidia GForce 8600), my cpu (quad core core 2)? (In reply to comment #5) > What is the solution for "slow native painting."? Is it a bad X server > (currently vanilla fedora 12), my graphics card (NVidia GForce 8600), my cpu > (quad core core 2)? no idea. but it's something we can't fix in netbeans. try more recent jdk update. Stanislav, Take a look at http://statistics.netbeans.org/analytics/exception.do?id=628793 This has nothing to do with slow native painting. It has to do with the painting thread waiting on an expensive operation such as Code Format of a large file. It seems to me the exception reporter should subtract this time (waiting on a lock) from the actual time the operation took and/or figure out the operation that was really slow was code-format, not the painting thread. DiffSidebar.paintComponent() calls into editor.Utilities.runViewHierarchyTransaction(), versioning team, please evaluate, thanks. (more than 200 reports -> P2) > DiffSidebar.paintComponent() calls into editor.Utilities.runViewHierarchyTransaction(), versioning team, please evaluate, thanks.
> (more than 200 reports -> P2)
editor please evaluate
The problem is that repainting is blocked by formatting. The times are really ridiculous - it is real P2 IMHO. The formatting is either triggered by the user or in some reports automatically on save which is even worse. Looking at the last couple of profiler snapshots coming from 7.3 beta 2, AWT EDT is waiting an extremely slow javascript reformatting holding document lock. igorrius, can you provide document for testing? What is the size of document? I don't think formatter is extremely slow - it may take some time for huge, completely wrongly formatted (minified) files. Slow operations are not in the formatter itself, but in actual document modifications - 36s out of 39s. I went through the last couple of 7.3 reports and only two of them (igorrius) are JS related and both of them represents the same file. The file is also not parsable for some reason. We need the file to evaluate. igorrius, can you share a file causing this? Created attachment 135034 [details]
Sample Javascript file
Here is a sample Javascript file that takes 12 seconds to format on my powerful desktop PC. Please let me know if you need anything else to reproduce and fix this issue.
I should note I am using: Product Version: NetBeans IDE Dev (Build 201305232300) Java: 1.7.0_21; Java HotSpot(TM) 64-Bit Server VM 23.21-b01 Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b11 System: Windows 7 version 6.1 running on amd64; Cp1252; en_CA (nb) User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev *** Bug 229278 has been marked as a duplicate of this bug. *** (In reply to comment #17) > Created attachment 135034 [details] > Sample Javascript file > > Here is a sample Javascript file that takes 12 seconds to format on my powerful > desktop PC. Please let me know if you need anything else to reproduce and fix > this issue. This took about 2 seconds for me. It might be influenced by OS and FS. Note that whenever you format a file the major portion of time is spent with document changes - if the document is completely broken (in terms of formatting) the formatting is slower. This is the case of the sample, every line is reindented as original doc is using tabs. Formatting of this document once formatted initially is immediate. Is there a reproducible case where minor portion of the document is changed and it takes a long time? *** Bug 229041 has been marked as a duplicate of this bug. *** Reproducible test case requested. Also there has been improvements recently for project specific formatting settings. |