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: | Code completion gets slower and slower in extremely long methods | ||
---|---|---|---|
Product: | java | Reporter: | _ wadechandler <wadechandler> |
Component: | Editor | Assignee: | Dusan Balek <dbalek> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | gsporar, tzezula |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | .java file which highlights the issue |
Description
_ wadechandler
2007-08-26 09:16:25 UTC
I was using the file I'm going to attach to study some nbuser comments about Eclipse and NetBeans. From what I can tell on my two systems, 3Ghz, 2GB RAM, Windows XP and OpenSuSE 10.2, the NB code completion is as fast as Eclipses except in these situations where things get extremely large. I'm not sure about classes and what it would take to make all the classes code completion act this way as I couldn't come up with a class, even with real code from real projects which made code completion slow as it does in the large method, but I thought being able to see this in action might help track down an issue, according to others, which occurs in different areas. I will say that in my comparison for Eclipse and NB to be on par I had to reduce the auto-completion delay by going to "Tools|Options|Advanced Options(button)|Editing|Editor Settings|Java Editor" and the field is "Delay of Completion Window Auto Popup" and changing it to 50 or 100. After that the only real difference I could see was in the extremely large method you'll see in the file soon to be attached. Created attachment 47404 [details]
.java file which highlights the issue
When you open the .java file you'll notice the package. It will have to be put into a folder hierarchy to match the package and put into a project to use it in the IDE. You will notice I have comments "//try code completion here" which you can search for. When inside the someLargeMethod method notice how far down you have to get before it starts really slowing down. It seems well over 1000 lines of code at which point methods should really be split up and refactored into smaller ones, but others may be experiencing issues in smaller methods. I don't know. I just know the testing I have done so far, and I'm not exactly sure how this would affect the form modules code completion in different areas where the editor is actually editing portions of the larger method initComponents...it can get very large. I'm writing a class to generate any number of classes from a template so we can test completion with extremely large projects. Extreme numbers of classes in one package, in one project, in multiple dependencies etc. This one was pretty easy to find, so I thought I would get it posted fast. The CC is always re-parsing the current method from the beginning to the caret position, which probably causes this problem. It might be enough to re-parse only a block or a statement, I do not know. I do not think We will manage to improve this for NB6.0. Throwing out an idea for the future. Maybe there could be a queue kept which keeps track of lines of code as they are changed in the editor. As the user is typing the queue would be added to and a background thread could process any changes it receives. This should then keep them all caught up. When the user gets to where they need CC, if there are any left in the queue, then those left in the queue can be caught up. Theoretically the queue would almost always be caught up except for maybe the previous line edit. With it being small parses at a time and in the background it should not impact the user experience and CC would be fast. Obviously the queue would need to be a FIFO. We did many improvements in 6.1. Namely incremental parsing. Please reopen if it still too slow. Thanks Awesome...I'll get a chance soon to double check this on my systems with the file I attached. It gives the best example I could come up with. I will update my trunk sources on my other laptop soon and try it out and will let you know the results. Thanks for all the hard work. This seems to be working much better now. I went ahead and marked it as verified. I meant to do this a long time ago, and then I ran across this issue again while putting together some points. |