Bug 113806

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.