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:-
------- 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.
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!)
This problem was reported by NetCAT 6.7 participant.
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.
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
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
I actually have written this entire post while waiting for "Scanning in progress....please wait" after ctrl-clicking on
a type :-(
> 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
http://hg.netbeans.org/jet-main/rev/4047114820db - this should fix the problem with clean & build causing one more
http://hg.netbeans.org/jet-main/rev/d7b226b07e18 - should have been part of #4047114820db otherwise CslTestBase is broken.
http://hg.netbeans.org/jet-main/rev/e467369ed201 - this should fix the problem with persisting index data from discarded
Verified discarded changes fix in trunk
verified fix of unnecessary rebuild
Integrated into 'main-golden', will be available in build *200906111401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Vita Stejskal <email@example.com>
Log: fixing some aspects of #166714; clean & build forced reindexing of the project
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.
using daily build 200906131401... I can't see any improvement. I guess I'll wait for rc3
verified fix of unnecessary rebuild and discarded changes fix in RC3
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
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.
Which daily build should I use ? The one a few days ago didn't have the fix from what I could tell.
> 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.
Created attachment 83636 [details]
The patch for non-blocking class index
I'm still testing the patch, but will apply it trunk soon.
just checked rc3 and as you know the problem still exists but also I got a new issue #167193 where the IDE locked up.
I just pushed the patch for 'goto type is blocked' to jet-main - http://hg.netbeans.org/jet-main/rev/644622e0a926
Integrated into 'main-golden', will be available in build *200906180201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Vita Stejskal <firstname.lastname@example.org>
Log: #166714: applying tzezula's patch which changes locking semantics of ClassIndexManager
yep, this seem to work well. Petty that's not part of 6.7
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
Looking at http://wiki.netbeans.org/NB67RC3GoNoGo it appears that this should be included in the final version, is that
The fix has been ported into the release67_fixes repository.
verified Go To type block