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.
After I select (not double click...just select) a file in the Project window, and then go to the editor window and click within it inside an open .txt file, it takes between six and eight seconds for the cursor to come back alive. Going from the editor to select a file in the Project window takes about three seconds. Neither one of these should take that long in a machine with 2gig of memory. Here is some info about my setup: Product Version: NetBeans IDE Dev (Build 200710170000) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Note that I just tried using a .java file instead of a .txt file, and going from the Project area to a java file is much faster than going to a .txt file. Both files are roughly the same size (about 150 lines). This happens time and again...could there be some sort on syntax highlighting that should be turned off when looking at a .txt file perhaps?
FWIW, I just ran the same tests with the same files using Eclipse, and in that IDE the toggle is almost instantaneous, so I am fairly sure it is something that Netbeans is doing and not my configuration.
Please capture several threaddumps to help us find out where is the problem.
Could be the same problem as issue #119393. Please generate some thread dumps while the IDE is stale. Thanks http://wiki.netbeans.info/wiki/view/GenerateThreadDump
FYI: I can reproduce the problem (on singlecore) when switching from java source to a (even very small) text file. Switching between two java sources is much faster. I managed to take a thread dump during the switch and, surprisingly, while AWT is painting, the "Java Source Worker Thread" is working like crazy in RepositoryUpdater$CompileWorker.run(). I'll attach the thread dump. Note: I can't say how long does the repository updater really take, but I caught it there twice. I can't even say whether is does the same in case of java->java switch.
Created attachment 51290 [details] Thread dump from slow switching between java and text files.
Let's see what the gurus' got to say...
I do not know where exactly is the problem, but from the original report, I can see that switching to txt file is slower than to java file. I am not sure why the thread dump looks like this. Reassigning to performance.
Well, I did my bit of analysis already. It's your turn now to explain why the hell the RepositoryUpdater parses (some) file, when all I did was switching from unmodified, settled java editor to a text editor. The visible slowdown seems to be caused by another thread that started consuming the CPU just in time it is desperately needed by new editor painting. I have not profiled it, though.
Well, the RU starts parsing one (or two, on Win) seconds after focus lost. So the question is why it takes it one (or two seconds) to start painting the editor?
And, please note that this issue is not about switching tabs in editor (which you measured), but rather about switching between Projects and editor and back, using text file, not Java. There are other issues about switching tabs in editor.
That's interesting. I did the thread dump faster than 1s after the switch, I believe Maybe there was some additional delay before the JVM reacted to the signal? The complete switch took less than 2s for me (which is noticeably longer than java->java).
darrinps, we still need the thread dumps from you. I don't seem to be able to currently reproduce the problem you describe (switch between projects tab and text file).
Created attachment 51307 [details] Thread dump going from Projects tab to editor text file
Added thread dumps as requested. Note that this is a dual core pentium with 2 gig of memory.
So the problem is somehow related to the filesystem performance. Reassigning to Radek, he might ask additional question, but the first two should probably be: * Are your source files or userdir on a networked drive? * Were you doing some disk-heavy activity at that time?
*** Issue 119393 has been marked as a duplicate of this issue. ***
* Are your source files or userdir on a networked drive? All are on the network...the java and the text files. Java to java is fast, but java to text is slow. Also please remember that doing the exact same thing (toggling from one to the other) is nearly instantaneous in Eclipse. I was trying to use Netbeans on one of the same projects I have in Eclipse so I could test for things just like this that stood out. * Were you doing some disk-heavy activity at that time? Nothing going on at all...and this happens time and again...very repeatable.
This issue was reported by NetCAT participant.
most of masterfs perf.are done, so please check if there is still the same problem with your configuration. If so, please reopen