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.
This bug was originally marked as duplicate of bug 183421, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE Dev (Build 201008050001) VM: Java HotSpot(TM) 64-Bit Server VM, 16.0-b13, Java(TM) SE Runtime Environment, 1.6.0_18-b07 OS: Linux User Comments: tbrunhoff: After a refactor -- renaming a member variable. Maximum slowness yet reported was 3217 ms, average is 3217
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.