Bug 166714 - [67cat] "goto type" is blocked
[67cat] "goto type" is blocked
Status: VERIFIED FIXED
Product: editor
Classification: Unclassified
Component: Parsing & Indexing
6.x
All All
: P1 with 3 votes (vote)
: 6.x
Assigned To: Vitezslav Stejskal
issues@editor
67patch1-verified
: PERFORMANCE, REGRESSION
Depends on: 167193
Blocks: 167399
  Show dependency treegraph
 
Reported: 2009-06-08 12:38 UTC by David Strupl
Modified: 2009-07-16 11:10 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
The patch for non-blocking class index (12.25 KB, text/plain)
2009-06-16 15:18 UTC, Vitezslav Stejskal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2009-06-08 12:38:55 UTC
Spin off issue #161367.

------- Additional comments from nleck Sat Jun 6 05:22:33 +0000 2009 -------

Sorry need to re-open as the regression is there with one extra step as soon as you touch the file the "goto type" is
blocked and this DID NOT HAPPEN IN 6.5

performance regression in 6.7rc2 see:-
http://www.netbeans.org/nonav/issues/showattachment.cgi/83267/nb_scan.ogg

http://www.netbeans.org/nonav/issues/showattachment.cgi/83269/nb_scan-6.5.ogg

------- Additional comments from nleck Mon Jun 8 01:15:47 +0000 2009 -------

Created an attachment (id=83291)
scan is out of date

------- Additional comments from nleck Mon Jun 8 01:22:09 +0000 2009 -------

After making the performance regression movie in the previous comment, the file WASN'T saved. I actually even restarted
my IDE and noticed all these red marks... The indexer had stored the information of a Java file that wasn't ever saved.
Thus now out of date and will be until I change the Java file again.
Comment 1 Marian Mirilovic 2009-06-08 13:44:47 UTC
Honestly I do think it's a serious regression on our side : 30s vs. 1s :( 
I am not sure we will be able to fix it, but as I promised in original issue -> we'll do our best (Vita thanks a lot!)
Comment 2 Jiri Kovalsky 2009-06-08 13:56:45 UTC
This problem was reported by NetCAT 6.7 participant.
Comment 3 nleck 2009-06-08 21:56:15 UTC
These movies were recorded on a 8 cpus 12 gigs local machine. The Unix box that I share with a number of other
developers has much less resources per user and the main project has about double the source files. So the pain levels
are high on the project scanning issues. 
Comment 4 twolf2919 2009-06-10 02:36:32 UTC
I hope this gets fixed.  Here's my experience with RC2 (quoted from my nbusers post):

How to get annoyed in two easy steps:

1) Hit Clean/Build & wait for it to be finished
2) Do any of three common operations: type (ctrl-o), go to definition (ctrl-click on a type), or run the program (play
button)

I *always* end up waiting for 1-2 minutes while a dialog reminds me to wait while scanning is in progress.  As an aside:
before you try step (2), there isn't even an indication in the status area that scanning is in progress.

This is on a simple (but large) J2SE project with ~3800 java files and ~100 3rd-party jar files.  I'm on Ubuntu 9.04
running the latest JDK (1.6_14) on a 2GB core2duo laptop, giving NB 768MB of heap.  All files are local (no networking
involved).

I actually have written this entire post while waiting for "Scanning in progress....please wait" after ctrl-clicking on
a type :-( 
Comment 5 Marian Mirilovic 2009-06-10 08:59:07 UTC
twolf2919 : 
> I *always* end up waiting for 1-2 minutes while a dialog reminds me to wait while scanning is in progress.  As an aside:
> before you try step (2), there isn't even an indication in the status area that scanning is in progress.

this is separate issue - see issue 166527 - we plan to fix this into NB 6.8

Comment 6 Vitezslav Stejskal 2009-06-10 15:03:05 UTC
http://hg.netbeans.org/jet-main/rev/4047114820db - this should fix the problem with clean & build causing one more
unnecessary rebuild.
Comment 7 Vitezslav Stejskal 2009-06-10 21:17:09 UTC
http://hg.netbeans.org/jet-main/rev/d7b226b07e18 - should have been part of #4047114820db otherwise CslTestBase is broken.
Comment 8 Vitezslav Stejskal 2009-06-10 23:17:28 UTC
http://hg.netbeans.org/jet-main/rev/e467369ed201 - this should fix the problem with persisting index data from discarded
editor changes
Comment 9 Jiri Prox 2009-06-11 15:48:08 UTC
Verified discarded changes fix in trunk
Comment 10 Jiri Prox 2009-06-11 16:28:20 UTC
verified fix of unnecessary rebuild
Comment 11 Quality Engineering 2009-06-11 18:42:51 UTC
Integrated into 'main-golden', will be available in build *200906111401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/4047114820db
User: Vita Stejskal <vstejskal@netbeans.org>
Log: fixing some aspects of #166714; clean & build forced reindexing of the project
Comment 12 Vitezslav Stejskal 2009-06-14 07:55:52 UTC
The fixes for 'clean & build causing reindex' and 'persisting index data from discarded editor changes' have been
transplanted to release67 as follows:

4047114820db - http://hg.netbeans.org/release67/rev/0a960f862bbe
d7b226b07e18 - http://hg.netbeans.org/release67/rev/37d23df55acb
e467369ed201 - http://hg.netbeans.org/release67/rev/0086742488d3

I still don't have a fix for the 'goto type' dialog being blocked. The reason why it works in 6.5 is that in 6.5 editor
modifications did not trigger dependencies compilation. This was one of the problems causing incorrect error badges. In
6.7 we fixed that and when a class is modified in the editor, it is recompiled including all the classes that depend on
it. This may take some time depending on how many dependent classes there are. Since the recompilation also updates the
class index, it locks the index for writing and blocks all other access to the index (eg. from goto type).

The index does not necessarily have to be locked, I think, at least not all the time. But changing this is likely to
have some unwanted consequences and I am not very keen on doing this at this stage of the game. Btw, we plan to go over
usecases like this one in #133943 and #165245.

I'll leave this open and we still have several hours before the RC3 build starts, but I'm becoming pessimistic on this one.
Comment 13 nleck 2009-06-15 01:12:07 UTC
using daily build 200906131401... I can't see any improvement. I guess I'll wait for rc3 
Comment 14 Jiri Prox 2009-06-15 13:43:52 UTC
verified fix of unnecessary rebuild and discarded changes fix in RC3
Comment 15 Marian Mirilovic 2009-06-16 13:30:21 UTC
Hi all,
thanks to tzezula and vstejskal, those were working last couple days on this issue and found & prepared a fix. We've
already done review of the fix and started to test it.

I have to say that after detailed review and long discussion between QE & Dev we realized that this fix is too risky for
integration into release67 so late in release cycle and it will require extensive testing, that can't be accomplished
before NetBeans 6.7 FCS ... so, here is QE's decision :

1. we definitely will address this problem in NB 6.7 Patch 1 (scheduled for mid-July)

2. if needed we can provide a patched module (includes this fix) for NB 6.7 as attachment into this issue right after NB
6.7 release

3. we (QE) will test this fix in trunk and proceed with regular patch testing of all affected areas before GO for Patch 1 

vstejskal, please integrate the fix into trunk.

nleck, please ... if you are still willing to help us to get this issue fixed as soon as possible, try latest build from
trunk once it's integrated (you will be notified by issuezilla - added comment by "qa" user with link to the build). If
you'll approve that our fix fixed problem you are facing with "Go To Type", we'll prepare a patch for NB 6.7 and attach
it into this issue, before it will be officially released in NB 6.7 Patch 1.

Thanks for understanding and all your help.
Comment 16 nleck 2009-06-16 14:27:24 UTC
Which daily build should I use ? The one a few days ago didn't have the fix from what I could tell. 
Comment 17 Marian Mirilovic 2009-06-16 14:29:01 UTC
> Which daily build should I use ? The one a few days ago didn't have the fix from what I could tell. 

please wait a minute ... it's integrated into trunk yet ... as I said, you'll be notified by issuezilla (comment added
by "qa" user, once the fix is ready to be tested in Dev build (with the link to the build) .... thanks in advance.
Comment 18 Vitezslav Stejskal 2009-06-16 15:18:39 UTC
Created attachment 83636 [details]
The patch for non-blocking class index
Comment 19 Vitezslav Stejskal 2009-06-16 15:20:11 UTC
I'm still testing the patch, but will apply it trunk soon.
Comment 20 nleck 2009-06-17 01:39:08 UTC
just checked rc3 and as you know the problem still exists but also I got a new issue #167193 where the IDE locked up. 
Comment 21 Vitezslav Stejskal 2009-06-17 12:40:15 UTC
I just pushed the patch for 'goto type is blocked' to jet-main - http://hg.netbeans.org/jet-main/rev/644622e0a926
Comment 22 Quality Engineering 2009-06-18 06:59:26 UTC
Integrated into 'main-golden', will be available in build *200906180201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/644622e0a926
User: Vita Stejskal <vstejskal@netbeans.org>
Log: #166714: applying tzezula's patch which changes locking semantics of ClassIndexManager
Comment 23 nleck 2009-06-18 12:32:29 UTC
yep, this seem to work well. Petty that's not part of 6.7
Comment 24 Jiri Prox 2009-06-18 14:33:08 UTC
Yes, it is pitty, but the fix would be too dangerous, we will integrate in first patch. You can use trunk builds
meanwhile, there should be little difference to fcs.

Thanks for testing

Marking as verified so the fix can be integrated

Comment 25 nleck 2009-06-19 10:40:11 UTC
Looking at http://wiki.netbeans.org/NB67RC3GoNoGo it appears that this should be included in the final version, is that
true ? 
Comment 26 pgebauer 2009-07-03 11:56:35 UTC
The fix has been ported into the release67_fixes repository.
http://hg.netbeans.org/release67_fixes/rev/dd5fab9cdf99
Comment 27 Jiri Prox 2009-07-16 11:10:52 UTC
verified Go To type block


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