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.
Netbeans 6.1 (Trunk, but since B6.1 and eariler) has a performance issue when having in rails large JavaScript Frameworks (i.e. EXT). Indexing of these takes hours and requires lot of memory (need to increase permgen to about 1GB to make it work at all, otherwise IDE hangs). Also after Index, the RHTML/ERB editor is unusable. The edintg hangs almost always when trying to autocomplete for about 10-30s, so it fact no edditing really possible. This affects specially HTML/JS code included in RHTML. This behavior was not in 6.0, so I believe it was introduced with new indexing/JavaScript functionality.
Hi, what do you mean exactly by "since B6.1 and earlier"? What specific build did you try? The latest daily builds can be downloaded from: http://deadlock.netbeans.org/hudson/job/trunk/lastSuccessfulBuild/artifact/nbbuild/dist/zip/ It would help if you could attach the sources/project for which this is happening - this will help us reproduce the issue. Thanks!
Hi Pach, I've tested with specifically the Ext library myself and I didn't observe the same problem. Which exact build are you using? How did you include Ext in your project? Do you have ext-all-debug.js in your project? A whole ext install tree? In a recent checkin I made NetBeans skip file FOO.js if a file named FOO-debug.js exists, so it should only index the ext library once. Can you give a bit more information on what you do in the RHTML file when it's unusable. What exact expresisson are you auto completing on? I assume this is in a <script> block in an ERB file, not in Ruby, right? Finally, would you mind grabbing a thread dump or two while the IDE is hanging and attaching it so I can see where the CPU is swamped? http://wiki.netbeans.org/GenerateThreadDump
Pasting a private reply from the submitter: "Hi, I have been trying the builds (almost every week, latest 200803141205). The situation is the same. I have doubts it is related to big ext javascript file. I have tried project without this library and they seem to perform o.k. - For me this indicates clearly performance issue somewhere in indexing/source code completion. To reproduce, just go to EXT 2.0 library and attach it in your rails project (public/ext). I do have both there debug and build versions. Build version is also specific that it has ALL whitespace stripped, so in fact the whole script is on single line. Maybe this may cause some issues also? I also have there DOJO library, so maybe this may also have some negative impact? I am unable to give you sources for the project, as it is quite huge and contains some licensing products in it, unfortunately. Also please consider this not only performance issue. In fact the RHTML editor is not usable at all, and I have to still stick to 6.0, as 6.1 has these issues."
I've tried adding both Dojo and Ext version 2.0.2 to my own Rails project with a fresh userdir and the full indexing takes only 4-5 seconds (this is on a OSX dual core box running Leopard). I've sent instructions to Pavel for how to generate thread dumps so we can see what the IDE is so busy doing during this 10-20 minute delays. He also sent me a stacktrace generated by the Rhino parser where it's confused about some syntax in one of the files. I'm going to try to emit additional information in that part of Rhino such that we can see which file is generating the problem, but since this stacktrace is listed only once that shouldn't be related to the huge performance problem.
I've been writing to Pavel offline and I just heard from him that this issue seems to be fixed in the latest builds: "After first tests it seems that that annoying bug of rhtml editor disappeared. I will switch to this release (200804050004) and will use it as primary ide for while. However the increased "cpu" usage thing is still there, although when indexing finishes, seems that on next reboots, etc. the reindexing does not executes again." (The first time indexing once can't be helped - we need the index information to be able to offer code completion for the user's own functions etc - but since it's only happening once it has limited impact). If others run into this in the future, please run the IDE with this flag: -J-Druby.indexerbug.level=300 This will add extra entries in the log with some diagnostic information to pinpoint what's going on during startup indexing.