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.
Created attachment 130896 [details] messages.log Note: Running latest nightly (20130131) and latest custom builds from web-main also. While holding down the CTRL button, hover the mouse over some function/variable for a while and try left-click on it. The whole application slows down and stalls ... for seconds sometimes. Eventually it will go to the declaration/definition. To test, just open the "ToDo" sample PHP application, open up /dao/TodoDao.php and go to the save function. Hold down the CTRL button, and then hover over the getId() call on the $todo variable. Log attached but this is generally what it is: INFO [org.netbeans.modules.parsing.impl.TaskProcessor]: Task: class org.netbeans.modules.csl.editor.semantic.SemanticHighlighter ignored cancel for 760 ms. WARNING [org.netbeans.modules.csl.editor.hyperlink.GoToSupport]: Inconsistent DeclarationFinder org.netbeans.modules.php.editor.nav.DeclarationFinderImpl@1af4092 for offset 496 INFO [org.netbeans.modules.parsing.impl.TaskProcessor]: Task: class org.netbeans.modules.csl.editor.semantic.SemanticHighlighter ignored cancel for 518 ms.
The pasted messages are just an indication that something was wrong. The Semantic Highlighter itself more or less just calls and post-processes lower layers, so if there's some issue, it's likely to be in a particular language implementation. Please provide an exception report, or run the self-sampler & attach the result snapshot, so we can see where the CPU is consumed. The issue did not appear during my testing. Please also look for definition of defect priorities. This one is not P1, and I'd say that it is neither P2.
Created attachment 131008 [details] selfsampler npss
Added self-sampler, there is no exception report for it, that's why I manually entered this issue. I can do some more tests here on this side if you need me to. Padraig.
Probably it's caused by new "deprecated" elements support. Since it's very "index depenedent" (all method calls, filds accesses and such has to be resolved and checked). Probably I'll make some setting option to enable this support (with a warning that it can slow down the IDE).
(In reply to comment #4) > Probably it's caused by new "deprecated" elements support. Since it's very > "index depenedent" (all method calls, filds accesses and such has to be > resolved and checked). Probably I'll make some setting option to enable this > support (with a warning that it can slow down the IDE). An option would be great for it. What functionality would be lost though if the option was set to off? Would the "go to declaration/definition" be gone or still working?
That "deprecated" feature just "strikes through" deprecated elements in editor. So you see that you use some deprecated class/method/field/...
(In reply to comment #5) > (In reply to comment #4) > > Probably it's caused by new "deprecated" elements support. Since it's very > > "index depenedent" (all method calls, filds accesses and such has to be > > resolved and checked). Probably I'll make some setting option to enable this > > support (with a warning that it can slow down the IDE). > > An option would be great for it. What functionality would be lost though if the > option was set to off? Would the "go to declaration/definition" be gone or > still working? I guess it'll just turn off the "deprecated" functionality?
Oops, mid-air collision in Bugzilla. Thanks for the reply. Ya, so it would be fantastic to have the option to turn the "deprecated" functionality off. I can live without knowing if an item is deprecated. I would much rather that holding Ctrl and moving the mouse would be much more responsive! Thanks.
Yep of course, option will be for enabling/disabling visualisation of deprecated elements (which is handled in SemanticHinghlighter and which blocks parsing thread, so no other parsing dependent feature can be processed - e.g. go to declaration). Colision again ;) The best would be if I would be able to make that "deprecated" functionallity fast :) But not sure if it is possible in the current infrastructure.
Ya, making it fast would be ideal, but how long would it take to make it fast, like you said with the current infrastructure if mightn't be possible. So, a quick-fix would be the option to turn it off until you've got time to implement a proper fix for it. At least with the option, we can get back to enjoying a more responsive Netbeans! :)
Just keep in mind that we are talking about development build. It doesn't have to be fast and fully responsive...it's here for developing purposes ;) Yes I have it in my todo, so I'll look at it of course, but not sure exactly when.
That's true, I always build from web-main every day and use it here at my job. I like having the dev build just to have the newest features and to see what's under development. I know there will always be issues with it, and I like helping iron out those issues too. So, thanks for the help and please keep my informed here!
Created attachment 131096 [details] Speed up creating method elements from index This patch can speed up creating method elements from index (which is slow in the snapshot) because it resolves its parameters and return types on demand.
I've applied the patch to the latest pull from web-main. It seems to help a bit but I'm still getting freezes, this is how I get the freezes now: Essentially it freezes if you Ctrl+Click something before the "Navigation" window is updated. I've attached a self-sampler
Created attachment 131106 [details] self-sample after applying "Speed up creating method elements from index" patch
It was more likely note for me :) But it's great that you are able to test it live. I'll attach just one patch. It would be great, if you can apply both of them and test'em together. Thanks.
Created attachment 131108 [details] Added more caching and improved finding of variable scope.
I've applied the two patches and it made a good difference. Some points: #1 Keep holding down CTRL and then, In class1, click on "new Class2()" to open class2, and then (while still holding CTRL, click on "parent::__construct()" to open class3 #2 By not holding CTRL while switching between the files it seems like the speed has greatly improved but still a bit jittery. #3 By putting the mouse over the item, and CTRL+Clicking it and letting go of CTRL quickly is mostly working great. In general it seems holding CTRL before clicking, and holding CTRL after clicking is causing the issue. Also I've a feeling it's related to the "navigator" tab not being fully loaded or whatever the background to that is. I'll attach a self-sampler of point #1 now.
Created attachment 131114 [details] self-sampler of point#1
(In reply to comment #19) > Created attachment 131114 [details] > self-sampler of point#3 Sorry, I meant self-sampler of point #1, the worst one.
Not sure how this "holding CTRL before, during and after clicking" works and how it should behave. Maybe Svata can explain that? Svato? But what is the result after applying those patches? IDE should be faster and more useable (from Semantic analysis point of view).
Ya it's much better than before, far more usable and responsive These are still coming up in the messages.log file, far less often though :) INFO [org.netbeans.modules.parsing.impl.TaskProcessor]: Task: class org.netbeans.modules.csl.editor.semantic.SemanticHighlighter ignored cancel for 193 ms. INFO [org.netbeans.modules.parsing.impl.TaskProcessor]: Task: class org.netbeans.modules.csl.editor.semantic.MarkOccurrencesHighlighter ignored cancel for 122 ms. WARNING [org.netbeans.modules.csl.editor.hyperlink.GoToSupport]: Inconsistent DeclarationFinder org.netbeans.modules.php.editor.nav.DeclarationFinderImpl@15d4b10 for offset 6,647 If you need me to do anything else just say here and I'll try it asap.
Thanks, I'll try to integrate better cancel() later. Not sure if tomorrow, maybe on Monday. Thanks for your help :)
No problem, I'll keep an eye out here if there's anything you need me to do.
I see some commits in the repo that are very similar to the patches linked above, does the version in the repo trump the patch files? I'm doing a build right now without the patches applied (just a straight pull from web-main) and I'll report back in a while about it. Also, a bit off-topic, when I do a build I execute the following command line: ant clean && ant build-nozip -Dcluster.config=php -Dpermit.jdk7.builds=true and delete "web-main\nbbuild\netbeans" and it takes >6 mins to build, is there a way to speed up the process?
Yes, I pushed some patches so probably these attached will conflict with em. You can test it without applying these ones. But in trunk is still missing some caching in semantic analysis (so I'm not sure if it will be fast as you wish :). I don't think. I'm building whole IDE for about 20mins :)
*** Bug 226081 has been marked as a duplicate of this bug. ***
*** Bug 226089 has been marked as a duplicate of this bug. ***
*** Bug 226214 has been marked as a duplicate of this bug. ***
Created attachment 131479 [details] Patch 3 Hi padraigdoran, please, can you fetch the latest sources and apply this patch? It could help a bit, hopefully :)
Hi, was away for a while. I'll do a pull from web-main and apply this patch. Should I discard the other patches? I know some of them are already in web-main anyway. So, pull & apply Patch 3 only?
Created attachment 131559 [details] Selfsampler after applying Patch 3 Applied Patch 3 to latest pull, cleaned out everything. The Ctrl+Clicks were very slow. I've attached a selfsampler. I got OutOfMemory exceptions too. When Ctrl+Clicking between large files the application halted for long periods of time and eventually ran out of memory. It does seem though that the Ctrl+Clicks are fast ONLY when the file I'm clicking from is fully loaded (i.e. has all the semantic analysis done to it, the Navigator pane is fully loaded, the function is selected in the navigator pane, and all occurrences in the file are highlighted)
Created attachment 131560 [details] messages.log after applying Patch 3 For above selfsampler, here is the messages.log file.
Resolving types of invocations/accesses is really expensive :( Damn it!
I wonder if it needs a rewrite or could it be improved by refactoring the code?
*** Bug 225634 has been marked as a duplicate of this bug. ***
The sluggishness happens also when you click a method in the Navigator window. It takes forever to jump to that method. Sometimes even before you can click on something, the navigator window takes forever to list all of the properties and methods.
As far as I remember it wasn't the case in NB7.2 I started feel it annoying after switching to NB7.3. Both: stable and dev build suffer from this issue (as well as I do ;) )
Every few weeks, I download a copy of Netbeans from the Hudson CI build server (http://bertram-tst.netbeans.org:8080/job/PHP-build/). I keep a few copies around just in case something happens and I can revert back. The NetBeans IDE Dev (Build 2013-01-24_09-04-16 ) version from Hudson seems to work ok for me. The original poster was using 20130131. That is a week difference. I bet the slowness was introduced with a commit between 20130124 and 20130131.
*** Bug 227380 has been marked as a duplicate of this bug. ***
Ok, so I removed that semantic analysis support of deprecated "invocation and access" elements due to performance problems. Thanks for your cooperation. Fixed in web-main #e940c673ce71
Hi Ondrej, I've done a clean build from web-main and NetBeans is very responsive now in the PHP files. Thanks for your help in resolving this issue.
*** Bug 227421 has been marked as a duplicate of this bug. ***
*** Bug 226949 has been marked as a duplicate of this bug. ***