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 # : 200809190201 ] [ JDK VERSION : 1.6.0_04 ] Using Go To File on a large project becomes unusable. this becomes an issue when working with large web projects with many js, xml or properties files.
Go To Type is also slow.
Could you please provide more details? Thread dump would be appreciated. http://wiki.netbeans.org/GenerateThreadDump
Created attachment 70145 [details] Go To File Thread Dump
Reporter's comment on mailing list: I have noticed that the performance of the Go To Type functionality is hit or miss when it comes to performance. Sometimes I can get almost instantaneous results, other times I am having to wait many seconds (~5-20) before I get results. I feel this is unacceptable given that on the same machine Eclipse and Intellij are orders of magnitude faster. Intellij begins showing results almost immediately and Eclipse takes no longer than ~1-2 seconds. So I did a little research and found the index cache where Netbeans stores class files and Lucene indexes. I have ~ 435 directories. Each directory has a Lucene index. I am not sure if the Netbeans code is pulling all those together at runtime or not, but I believe that it would be more efficient to combine these into a single index and allow Lucene to partition these as it sees fit. Has any one else experienced this behavior? I had a few other developers in the office install Netbeans and they experienced similar behavior. I will be filing another issue but I doubt it can be fixed until 7.0. I think this issue should be taken very seriously since it presents a bad experience to developers who are ready to leave Eclipse for Netbeans. David Freels P.S. Go To File is unusable still. This is even after the performance improvements (they did help) made the last time I filed an issue.
Go To File is file search, there is no index for files. It means it is strongly related how fast is your disk, how OS caches the filesystems etc. That is also reason why it gives you different results. IntelliJ indexes the files when started, that is the reason why it is so fast.
David provided the thread-dump. Removing INCOMPLETE keyword.
Note: For the Go To Type..., I have added additional logging to measure individual time consumed by providers: http://hg.netbeans.org/main/rev/b630fab2f56a Right now, you can switch it on with command line parameter: -J-Dorg.netbeans.modules.jumpto.level=FINE.
As I described above, Go To File is strongly affected by disk, filesystem, operating system etc. If you use large source-base, it is obvious that going throughout the whole disk will take a lot of time. Only the way how to improve behavior dramatically is to index all files, which will take some time during the start-up. But it is another discussion. Closing as WONT fix, as currently there are no plans to index all files.
1) In my project group there are 47983 java files, go to type takes in average less than 3 sec, except of the first run when the files are not hot. Intellij has faster go to type but as it loads the class index into memory it needs higher mx. 2) There was an issue in the Go to type causing Go to type not to cancel previous searches which slows it down, it was fixed in NB 6.5. 3) >I am not sure if the Netbeans code is pulling all those together at runtime or not, but I believe that it would be more >efficient to combine these into a single index and allow Lucene to partition these as it sees fit. Is a naive solution which unfortunately doesn't works at all, see the eclipse or intelliJ, there is the same partitioning of storages. Any modification, especially cp changes will be very expensive. The overhead on federation is not very high as nb doesn't use the query API and uses just the low level APIs and caches the index readers. 4) There is an RFE to improve go to file to use the index rather than the file search, scheduled for current + 1.
Unlike Go to type the Go to file doesn't benefit from an index. Either parsing API or some other module should provide file name index which can be used by this feature. This will dramatically decrease the time of search from minutes to seconds.
Tomáš just mentioned that he might look at the implementation one day.
I will do it this weekend.
Vita was faster and already implemented this.
*** This issue has been marked as a duplicate of 122639 ***