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 #229: Indexing (started when rubyapp was created) took over 6 minutes and 20 sec, on following machine. For exapmple, on the same machine takes indexing of java less than 1 minute and 40seconds. HW: P4 - 2,8GHZ ,1GB RAM SW: NetBeans IDE Dev (Build 200701150200) 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105 Windows Vista version 6.0 running on x86 cs_CZ (nb); Cp1250
It would be nice if we could make it faster, but it won't be easy. I basically have to run JRuby on every single file - all the library files and all the gem files (which includes all of Rails. If there was a way for me to run JRuby in a "skimming" mode (where it tracks things I need such as modules, classes and methods, but not method bodies (I do have to locate require statements so code outside of methods needs to be scanned) that would help. There are probably some other things which can be done here as well - I'll take a look with a profiler at some point.
(Note also that rdoc's RI generation does not seem faster.)
Fixed. Everything is now pre-indexed so it should only take a few seconds. (If you install your own libraries however or use another JRuby or Ruby interpreter than the bundled one, your indexing will still take a while.
Pretty cool (=fast)! v/c
It is perfect when you stick with the default bundled JRuby interpreter. But once you switch to your own ruby or jruby interpreter it still takes very long time. After I've changed to: - my custom JRuby build (trunk) it took about 5-7 minutes - Ruby 1.8.6 it took 15 minutes on 1.7GHz Pentium M.
On my Core 2 Duo (2x2.4 GHz) with 1GB RAM Netbeans is indexing the system (Debian sid) rails libraries linked from vendor/ for eight (8!) hours now and is at 36%. While it is blazingly fast with the bundled JRuby I can't use it with that, because ActiveRecord-JDBC is broken with PostgreSQL. Is there a way to generate the Cache so that it persists?
Ugh, let me make sure I understand: Are you saying you have -symbolic- links in your Rails project, under vendor/, that points to some (huge) directories in your debian system? Or are the symbolic links from within your ruby installation's gem directories? Or do you mean something other than symbolic links by "links" ?
P.S. ls -l `find . -type l`
Yes, the Debian "rails" command creates a vendor directory which points to the system rails libraries. Now that I have a look at it I got the suspicion that Nebeans is recursing the rails link. $ ls -l vendor/ lrwxrwxrwx 1 silvestre silvestre 29 2007-04-03 15:40 actionmailer -> /usr/share/rails/actionmailer lrwxrwxrwx 1 silvestre silvestre 27 2007-04-03 15:40 actionpack -> /usr/share/rails/actionpack lrwxrwxrwx 1 silvestre silvestre 33 2007-04-03 15:40 actionwebservice -> /usr/share/rails/actionwebservice lrwxrwxrwx 1 silvestre silvestre 29 2007-04-03 15:40 activerecord -> /usr/share/rails/activerecord lrwxrwxrwx 1 silvestre silvestre 30 2007-04-03 15:40 activesupport -> /usr/share/rails/activesupport lrwxrwxrwx 1 silvestre silvestre 1 2007-04-03 15:40 rails -> . lrwxrwxrwx 1 silvestre silvestre 25 2007-04-03 15:40 railties -> /usr/share/rails/railties And indeed Eclipse had apperently the same problem, which lead to a fix in Debian/experimental: rails (1.2.2-2) experimental; urgency=low * We cannot remove the link vendor/rails, but we can point it so it is not recursive. Recursive links seem to break eclipse and lack of vendor/rails breaks rails. The link target will create a non-recursive link, but a rails deployment that copies the rails directories will still contain recursive symlink. The problem is really in Eclipse though. It should handle recursive symlinks. -- Adam Majer <adamm@zombino.com> Tue, 20 Feb 2007 13:22:24 -0600 So, the new, experimental, version creates the following vendor directory: $ ls -l lrwxrwxrwx 1 silvestre silvestre 29 2007-04-05 18:37 actionmailer -> /usr/share/rails/actionmailer lrwxrwxrwx 1 silvestre silvestre 27 2007-04-05 18:37 actionpack -> /usr/share/rails/actionpack lrwxrwxrwx 1 silvestre silvestre 33 2007-04-05 18:37 actionwebservice -> /usr/share/rails/actionwebservice lrwxrwxrwx 1 silvestre silvestre 29 2007-04-05 18:37 activerecord -> /usr/share/rails/activerecord lrwxrwxrwx 1 silvestre silvestre 30 2007-04-05 18:37 activesupport -> /usr/share/rails/activesupport lrwxrwxrwx 1 silvestre silvestre 16 2007-04-05 18:37 rails -> /usr/share/rails lrwxrwxrwx 1 silvestre silvestre 25 2007-04-05 18:37 railties -> /usr/share/rails/railties Extrapolating from 10% after 8 minutes, it still will take 80 minutes though, and - I'm guessing - index rails twice. So my question is: Is there a way to generate the cache manually?
Great sleuthing, thanks! On JDK 6, I can detect symlinks. I should add some code to do that. To generate the cache manually, run NetBeans :) Seriously though, NetBeans checks if there is an index, and if not, it creates it. It will only be done once, so if you let it run to completion, it should not happen again. (Until I change the index schema, which I've done a couple of times - including yesterday, so if you - just- noticed it reindexing your stuff after updating, fear not - it's not going to index every time, only whenever the index schema has changed or if you install a new gem (only the new gem is scanned) or if you point to a new Ruby installation.)
I wrote earlier that the scanning will be performed only once - the first time. As I was falling asleep it hit me that this is not the case - because this is in the vendor directory of your Rails application! User directories (directories in your project, as opposed to in the Ruby installation or gem installation) are scanned every time (since they are more likely to have been edited, for example using other tools). Thus, you will be seeing this scan each and every time! Well that's pretty bad - I can't sleep. I'll take a quick stab at it. I'm also thinking I might prebake indices for a couple of dominant Ruby and Rails versions; the preindex zip files aren't very large < 500K total for both Ruby and Rails.
I have checked in a fix for the symlink issue. Detecting symlinks is expensive in Java (it relies on comparing File.getAbsolutePath with File.getCanonicalPath) so I'm only doing it a very specific scenario: files in a folder named "vendor". This should address the specific configuration issue we're seeing on Debian.
I have implemented preindexing for native Ruby as well now (provided it's a 1.8 ruby). This is available in version 0.58. I've also preindexed Rails 1.1.6 in addition to Rails 1.2.3 (even when installed in a native ruby tree).
this works fine now, at least for me, preindexing is great.
Reassigning this issue to newly created 'ruby' component.
Changing target milestone of all resolved Ruby issues from TBD to 6.0 Beta 1 build.