I use netbeans 6.1 (Ruby Edition) on windows XP, everything works fine except when I try to edit an RHTML file. The
editor's response is very slow when I start typing on the keyboard to enter some code into the file. I have to wait
about 10 seconds each time I type a letter, which makes it very annoying and take a very long time to edit a portion of
the code . Would you please take a look at this issue?
Can you generate a couple of thread dumps and attach them here so I can see -what- the IDE is busy doing during those 10
Are there any problems dumped in your IDE log view (View | IDE Log File) - perhaps you can attach that file here as well.
Created attachment 60919 [details]
Netbeans ruby ide 6.1 log
I have started the ide with nb.exe so I can generate the thread dump, the ide seems to be working properly when I
start it this way, it however performs slowely when I start it with netbeans.exe
I am not able to generate the thread dump but I have attached the IDE log for your review.
Thanks for the log file - unfortunately there are no signs in the log of any problems.
You don't need to start NetBeans in a console to get thread dumps. I think the Thread Dumps wiki page should be updated.
Using ctrl-break is the old way of generating thread dumps. The jstack tool is the new way. It's documented a bit
further down on the page.
Basically, start NetBeans the usual way you've been doing. Then open another console somewhere, and type
to list the running Java processes on your system.
% jps -lm
81225 sun.tools.jps.Jps -lm
81215 org.netbeans.Main --userdir /Users/tor/.netbeans/dev-clean --branding nb
Here "81215" is the process id for my IDE. I can now run the jstack command to get the thread dump:
% jstack 81215
Attaching to process ID 81215, please wait...
Assuming you're using JDK 6 this should work on Windows as well.
Make sure you generate 2-3 stack traces so that I can distinguish between long-running code and code that happened to be
running at the instant you generated the thread dump.
Created attachment 60928 [details]
NB61 ruby thread dump
I have attached the thread dump for your review, please take a look at the memory usage also, it is near 366M which is
a bit high for an IDE.
Thank you. There are a lot of interesting things going on here. I see menu warm up tasks running, I see editor settings
initialization happening and startup parsing. Was one or more of the thread dumps taken during IDE startup? Or are all
of these taken during the slow RHTML editing operation (e.g. hit a keystroke and wait for 10 seconds for a response as
listed in the first entry).
One thing did strike me though: In two of the thread dumps, I see one thread busily indexing code into Lucene. I did a
performance fix for this recently; too late for 6.1 but it will hopefully make it out in auto update. It made a huge
difference for PHP where startup indexing speed went down by a factor of 10. It's possible this fix would help you too.
Can you try a daily build and see if the performance problems are less evident there? If so that will be a stronger
incentive to push for the performance fix to go into the backport-to-61 branch and make it out on auto update. You can
get daily builds here:
Yes, the indexing is a big pain for me when using the IDE, as soon as the IDE loads it starts indexing the entire
Rails application, it first slows down the performance of the IDE dramatically as it boosts the memory use to over
300M which makes it impossible to use the IDE on a PC with limited memory.
The other issue with the indexing is that it takes long time to finish and makes me wait long time if I want to use
Is there any way to disable the indexing? I would appreciate it if you direct me to it.
Here's another thread dump for the same issue. For us it's really the only big issue with Netbeans, we're mostly editing
.html.erb files outside Netbeans because it's so painful, everything else is really nice.
Hope this helps. (see attachment)
Created attachment 60937 [details]
Captured while the IDE was in one of it's pauses..
thanks for the other thread dump. Can you try an experiment for me? Can you exit the IDE, move all the files/directories
faster? (Then move all the files back). If it is, I know what the bottleneck is for you and I should be able to
optimize that particular code. (The stacktrace suggests this is a bottleneck, but with just one dump it's hard to
distinguish long-running code from code which just happens to win the "what's running right now lottery".
that is causing the issues. There about 6000+ files in our js folder, dojo ajax libraries mostly.
I've checked in a quickfix for this in the trunk; try build #1801 or later from
Let me know whether this fixes things and I'll polish the fix and file requests to get it into the update center for 6.1.
Associated changeset: cf42ced50cde
Hmmm, my checkin -may- have missed the window for build #1801 so perhaps grab #1802 instead just to be safe - it should
kick off right after this one, e.g. an hour or two later.
BANG, you hit the nail on the head. Thanks!
breaking the JS security model.
(which is in front of Mongrel anyway).
Any progress on this issue please?
I am on Mac OS/X v 10.4.11, and am also experiencing this issue. Pauses usually occur for 5-10 seconds anytime I try to
type anything, making the editor unusable for any RHTML or .html.erb files.
I tried trunk build and it seems to be fixed. I nominate this issue for 61patch2.
can you please confirm the issue is fixed and verified?
It possible to backport into _fixes branch (what we use for patching) only VERIFIED issues.
Please set appropriate values for status/target milestone.
tor, could you please mark this issue as FIXED?
jskrivanek/QA, please verify this fix till 09-Jun-2008, so it can be part of NB 6.1 patch 2.
thanks a lot
This bug was fixed in the trunk (for 6.5) a while ago. It should be easy to port to 6.1. Just comment out some code in
JsModel. It's not used yet anyway.
Already verified in the trunk.
fix backported into release61_fixes branch
*** Issue 133776 has been marked as a duplicate of this issue. ***