Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 183727 - Go To Type takes 30+ seconds to load selected class
Go To Type takes 30+ seconds to load selected class
Status: RESOLVED FIXED
Product: groovy
Classification: Unclassified
Component: Grails
6.x
PC Windows XP
: P3 with 1 vote (vote)
: 7.2
Assigned To: Martin Janicek
issues@groovy
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-08 17:59 UTC by akochnev
Modified: 2012-04-26 10:28 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
A thread dump of the IDE (245.06 KB, application/octet-stream)
2010-04-08 17:59 UTC, akochnev
Details
another thread dump (63.83 KB, application/octet-stream)
2010-04-22 13:20 UTC, akochnev
Details
A thread dump from goto-file on 7.2 dev build (121.93 KB, application/octet-stream)
2012-04-23 19:03 UTC, akochnev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description akochnev 2010-04-08 17:59:46 UTC
Created attachment 96920 [details]
A thread dump of the IDE

In a medium size Grails project, I open the "Go To Type" functionality. After selecting the desired class, and hitting enter to select it , it takes 30+ seconds for the file to load in the editor - in the meantime, the whole UI is blocked.
Comment 1 akochnev 2010-04-22 13:17:50 UTC
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)
Comment 2 akochnev 2010-04-22 13:20:47 UTC
Created attachment 97858 [details]
another thread dump
Comment 3 Martin Janicek 2012-04-23 10:59:34 UTC
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
Comment 4 akochnev 2012-04-23 13:55:14 UTC
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...)
Comment 5 Martin Janicek 2012-04-23 15:19:16 UTC
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.
Comment 6 akochnev 2012-04-23 19:03:02 UTC
Created attachment 118659 [details]
A thread dump from goto-file on 7.2 dev build
Comment 7 Martin Janicek 2012-04-25 11:46:42 UTC
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.
Comment 8 Martin Janicek 2012-04-25 12:45:23 UTC
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.
Comment 9 akochnev 2012-04-25 12:49:13 UTC
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 !
Comment 10 Martin Janicek 2012-04-25 12:50:49 UTC
Sure thing. I'll push the changes during the next hour or two, so don't hurry ;]
Comment 11 Martin Janicek 2012-04-25 12:59:39 UTC
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
Comment 12 akochnev 2012-04-25 14:01:16 UTC
Just tried it out - works perfectly !
Comment 13 Martin Janicek 2012-04-25 14:03:06 UTC
Thanks for quick verification! I'm glad it helps.
Comment 14 Quality Engineering 2012-04-26 10:28:06 UTC
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


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