Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 134329 - Very slow response from the IDE when editing RHTML files
Very slow response from the IDE when editing RHTML files
Product: ruby
Classification: Unclassified
Component: Editing
All Windows XP
: P1 with 1 vote (vote)
: 6.x
Assigned To: Torbjorn Norbye
: 133776 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2008-05-01 15:36 UTC by theyaa
Modified: 2008-09-22 17:52 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT

Netbeans ruby ide 6.1 log (22.67 KB, text/plain)
2008-05-01 16:56 UTC, theyaa
NB61 ruby thread dump (117.93 KB, text/plain)
2008-05-01 20:32 UTC, theyaa
Captured while the IDE was in one of it's pauses.. (16.64 KB, text/plain)
2008-05-02 01:21 UTC, matt_tricks

Note You need to log in before you can comment on or make changes to this bug.
Description theyaa 2008-05-01 15:36:38 UTC
   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?

Comment 1 Torbjorn Norbye 2008-05-01 15:41:58 UTC
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
second pauses?

When you're editing text, is your caret inside a Ruby block of code, JavaScript, HTML or CSS?  (Or perhaps it's slow in
all cases?).
Are there any problems dumped in your IDE log view (View | IDE Log File) - perhaps you can attach that file here as well.
Comment 2 theyaa 2008-05-01 16:56:26 UTC
Created attachment 60919 [details]
Netbeans ruby ide 6.1 log
Comment 3 theyaa 2008-05-01 17:02:50 UTC
Hi tor,
  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.
Comment 4 Torbjorn Norbye 2008-05-01 17:33:35 UTC
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

jps -lm

to list the running Java processes on your system. 

% jps -lm
81225 -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.

Comment 5 theyaa 2008-05-01 20:32:49 UTC
Created attachment 60928 [details]
NB61 ruby thread dump
Comment 6 theyaa 2008-05-01 20:34:30 UTC
Hi tor,
  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.

Comment 7 Torbjorn Norbye 2008-05-01 23:26:33 UTC
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:
Comment 8 theyaa 2008-05-02 00:30:33 UTC
Hi tor,
 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 
the IDE.

 Is there any way to disable the indexing? I would appreciate it if you direct me to it.

Comment 9 matt_tricks 2008-05-02 01:19:41 UTC
Hi guys,

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)
Comment 10 matt_tricks 2008-05-02 01:21:07 UTC
Created attachment 60937 [details]
Captured while the IDE was in one of it's pauses..
Comment 11 Torbjorn Norbye 2008-05-02 01:53:19 UTC
Hi Matt,
thanks for the other thread dump. Can you try an experiment for me? Can you exit the IDE, move all the files/directories
in your Rails project's public/javascript/ to some other location, start the IDE, and see if RHTML file editing is
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".
Comment 12 simonmac 2008-05-02 07:10:18 UTC

I am having the same problems, and moving all the javascript out fixed it, so sounds like it is the parsing of them 
that is causing the issues. There about 6000+ files in our js folder, dojo ajax libraries mostly.

Comment 13 Torbjorn Norbye 2008-05-02 07:30:23 UTC
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
Comment 14 Torbjorn Norbye 2008-05-02 07:32:44 UTC
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.
Comment 15 matt_tricks 2008-05-02 10:07:02 UTC
BANG, you hit the nail on the head. Thanks!

Yeah we've just dumped all the whole Dojo libs into the public/javascripts dir, if we take it out it's fast again.
It's because of the way we're doing the virtual hosting so it's hard to move the javascripts anywhere central without
breaking the JS security model.

Looking forward to your optimisation, might see what I can do with rewrites to get the javascripts loading from Apache
(which is in front of Mongrel anyway).

Comment 16 theyaa 2008-05-07 20:46:15 UTC
Any progress on this issue please?
Comment 17 jjones013 2008-05-13 14:23:59 UTC
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.
Comment 18 Jiri Skrivanek 2008-05-14 08:16:32 UTC
I tried trunk build and it seems to be fixed. I nominate this issue for 61patch2.
Comment 19 jinb 2008-05-27 16:11:04 UTC
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.

Comment 20 jinb 2008-06-02 14:39:49 UTC
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
Comment 21 Torbjorn Norbye 2008-06-03 00:35:10 UTC
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.
Comment 22 Jiri Skrivanek 2008-06-03 10:09:14 UTC
Already verified in the trunk.
Comment 23 jinb 2008-06-05 10:43:57 UTC
fix backported into release61_fixes branch
Comment 24 Torbjorn Norbye 2008-09-22 17:52:55 UTC
*** Issue 133776 has been marked as a duplicate of this issue. ***

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo