Bug 183727

In 6.8, the issue was both in getting a list of classes when you hit Ctrl-O (Go To Type) and after you select the class. Now, after some of the indexing/performance fixes that went into 6.9 the first part is more bearable (takes a couple of seconds); however, still the second part of the process (that is, after you select which file/class you want to open) is still too slow to be usable (around 30 seconds to open the file after selection)

Created attachment 97858 [details]
another thread dump

Alex could you verify that this issue is still valid? I've tried to do this with the latest sources (which contains performance changes related to 180230) and it works pretty well. Thanks in advance

I was inclined to say that this is no longer an issue; however, I just tried it out and on the same project (web-main build, additional netbeans.conf options for indexing "-J-DIndexCache.size=2500 -J-Djava.index.useMemCache=true") it still took about 30 seconds to open the source file found using "Go To Class". As indicated in the original report, the issue is not finding the class in the "Go To Class" dialog (that works great after the indexing improvements), but rather just opening up the actual source file after the class is selected. 

While it is searching for the file after the selection is made, the IDE is completely blocked. When it returns, it steals focus from the currently active application (which is quite annoying - e.g. I'd try to open a file using Go To Class, while it's taking 30 seconds, I'd switch to another process and start typing something.. when the IDE returns, it steals my focus and as a result what I was typing before now goes into the IDE window resulting in unintended modifications to the source code)

A potentially aggravating issue here is that my grails project has a few additional sub-folders in the grails project that the IDE is indexing which might be resulting in yet more lucene indices - as far as I remember, Lucene creates an index per source root or something like that...)

Ok, thanks for the quick response. Could you please attach one new snapshot? From the old ones it seems that we are most probably compiling sources when the groovy file is opened, but I'm not sure yet.

Created attachment 118659 [details]
A thread dump from goto-file on 7.2 dev build

Thanks. From the snapshot it's clear that we are always calling ParseManager to parse AST when someone is using Go To Type. I'll take a look if we could somehow re-use our new caching mechanism to avoid this.

Alex I able to fix this but it will have also a negative impact (the file will be opened correctly and quite fast, but the cursor will be set on the first line, first column instead of current version where is positioned to the start of the class declaration).

It still seems to me much better than the current version (which is actually quite unusable for bigger grails projects), but I would like to know your opinion as well.

I think the cursor at the beginning of the file is just as good as the cursor at the beginning of the class (I really don't see any benefit from putting the cursor at the beginning of the class). 

I'll pull the latest changes and fixes and will give it a try later today. 

Thanks a lot for the quick turnaround !

Sure thing. I'll push the changes during the next hour or two, so don't hurry ;]

Ok, I was faster than expected. I've just tried the changes on the grails project with about 1000 files and it seems to work correctly (always within one or two seconds).

Fix change-set: web-main #2467194a50c0

Just tried it out - works perfectly !

Thanks for quick verification! I'm glad it helps.

Integrated into 'main-golden', will be available in build *201204260400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2467194a50c0
User: Martin Janicek <mjanicek@netbeans.org>
Log: #183727 - Go To Type takes 30+ seconds to load selected class