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 201208160001) VM: Java HotSpot(TM) Client VM, 23.2-b09, Java(TM) SE Runtime Environment, 1.7.0_06-b24 OS: Windows XP User Comments: bht: Closing 2 Java files in editor bht: Collapsing a tree node in Projects window some time after minimal editing trian: I was typing in the editor. I was editing a PHP file and I was typing within a HEREDOC block. This slowness, however, appears much too often and for many kinds of scenarios and to me is the single most annoying problem. Maximum slowness yet reported was 31453 ms, average is 11585
Created attachment 123285 [details] nps snapshot
Created attachment 123286 [details] nps snapshot Removed 1 line from a session bean, saved it and switched to the Projects window
in the snapshots attached, the problem appears to be the local filesystem performance, the JVM stack hangs in WinNTfilesystem native calls.
Created attachment 123299 [details] profiler screenshot
latest log have some enormous time of normalization, like WARNING [org.openide.filesystems.FileUtil]: FileUtil.normalizeFile(C:\bt\java\database\O-R-Mapping\JPA\Products\EclipseLink\issues\NullParameter\G1\G1_W\src\conf) took 6,078 ms. Result is C:\bt\java\database\O-R-Mapping\JPA\Products\EclipseLink\issues\NullParameter\G1\G1_W\src\conf 6 seconds to normalize path, it may be the reason(or have the same reason) for slow javac tasks also and may affect 216827. just a note, can you try to switch off your antivirus software to see if it may affect this issue too?
I can do that next time. But on that day, I worked about 8 hours with the IDE in one session and the NetBEans process used up 6 hours of CPU of my single 2GHz CPU. Most of this time I was actually waiting while CPU was at 100%. I doubt that this waiting was due to I/O bottlenecks or CPU starvation due to the virus checker consuming a significant part of the CPU power. I have never seen that. In addition, I have excluded most of my project dirs and IDE cache dirs from virus checking already but not all. I noticed something significant in this context as follows: The IDE scans directories of closed projects. How I would try to reproduce this: - Open a project - Close IDE - clear IDE cache - open IDE and let it finish the long initial scan - Check out a second version of the project or make a copy - Check out all dependent projects or make copies - Open all 2nd projects - let scan complete - Close all 2nd copied projects - Let the IDE settle down - Make a copy of the log file - (attempt to) delete 2nd projects with file system tools e.g. windows explorer - take note of which files could not be deleted. - take note of which files were scanned after 2nd projects were closed It looks to me that the IDE wakes up and scans closed project directories if I touch them outside the IDE. This is quite bad. My other thought is as follows: Since 7.2, during normal editing, the IDE eats all CPU whether it is scanning or not. I think this is partly due to JPQL parsing. Memory use grows very quickly during editing also. I am not sure but some swapping might be involved. If the CPU is at max already and scanning begins, then I/O is not likely to limit CPU use because most files will be cached anyway. So the scanning will probably create more CPU demand than anything else. My conclusion is that the IDE uses too much CPU. And most of that CPU use is probably wasted because I am not using more features than I use with 7.1 where performance is much better. Why would 7.1 be fast in comparison? 7.2 is slow because some strange features such as JPQL parsing. For those the IDE gets a bad reputation because one cannot turn this madness off. If that was an optional plugin then one could blame the plugin and the IDE would be ok.
An antivirus example: On average, for a 1 line change, a static private long field and save of a Java file, task manager records 5,000 I/O reads for the IDE and 50 I/O reads for the virus scanner. The virus scanner doesn't play any role in this. If it would, then 7.1.2 would also be slow because of it which it isn't. The counts for 7.1.2 are basically the same.
if JPQL parsing were the cause, it would be present in the snapshot attached. I could not find it, and as a matter of fact I could not find anything. Most threads are doing nothing, with exception of one parsing java files ("Repository updater worker") which is either suspended or waiting on native FS calls as well. And "W32 File Monitor" one being stuck in native method as well.
I have been trying to reproduce this scenario now. I think this would take 8 hours then I would get it again. As before, I opened all my usual projects twice. Still, memory usage as displayed within NetBeans was initially 200MBytes and the IDE is quite fast. Then memory usage grows slowly over time while performance deteriorates. Last time it was getting to 700MBytes after 8 hours with my option -J-Xmx800m in netbeans.conf. I don't have a good feeling yet what really happens so I will keep watching it.
I have made a series of experiments. At each step, I reduced the number of running processes and programs and then re-started the IDE and watched the log and CPU usage. At the end, nothing else except essential system services was running. I could not see a difference at all. On startup, I see a high number of FileUtil.normalizeFile log entries with up to 5,000 ms. This was surprising for class files and a few files that were open in the editor from the last session. Please see log file in bug 217412 for a simple startup. I have done everything I could find to tune my system for best performance including turning file indexing off and disk defragmentation. I am aware of some nasty things like zip files on the desktop which I have addressed as well. So my system is in good shape and really fast for its specifications. From my experience, some file I/O gets triggered by some editor action that competes with other I/O that the IDE does at the same time, most likely scanning caused by editing. The combination causes CPU starvation and therefore the FileUtil.normalizeFile doesn't get the CPU or I/O it needs to complete in time. I am absolutely sure about the fact that in my case NetBeans is the main factor in this, also because I did not see this with 7.1. The only significant improvement I could see was after after NTFS disk defragmentation. This is expected. But the issue remains. I have seen the log entries on a computer that is many times faster.
I still get this e.g. when navigating the package tree of a NetBeans standad ant project in the projects window. I am not doing anything maven related at this time. See exception reporter #625170.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss