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.
| Summary: | [67cat] "goto type" is blocked | ||
|---|---|---|---|
| Product: | editor | Reporter: | David Strupl <dstrupl> |
| Component: | Parsing & Indexing | Assignee: | Vitezslav Stejskal <vstejskal> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | dlipin, issues, jkovalsky, mmirilovic, nleck, pjiricka, sustaining |
| Priority: | P1 | Keywords: | PERFORMANCE, REGRESSION |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 167193 | ||
| Bug Blocks: | 167399 | ||
| Attachments: | The patch for non-blocking class index | ||
|
Description
David Strupl
2009-06-08 12:38:55 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!) 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 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 :-( 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
http://hg.netbeans.org/jet-main/rev/4047114820db - this should fix the problem with clean & build causing one more unnecessary rebuild. 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 editor changes 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) 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 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 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. 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) 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 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 true ? The fix has been ported into the release67_fixes repository. http://hg.netbeans.org/release67_fixes/rev/dd5fab9cdf99 verified Go To type block |