Bug 172464

Created attachment 87844 [details]
nps snapshot

If I understand the snapshot correctly, after pressing enter, the IDE tries to compile the code (or at least runs a
'CompilationJob' instance), because of what it requests source roots of the project(s) and because it is a bigger
project (netbeans profiler), it requires project source root(s) more than 20 times and subsequently calls loadProject
more than 40 times. That invokes 'createProject' more than 140 times... I do not need to continue, that is 100-200 file
operations.

I think this really should not happen for just one 'enter' after the javadoc comment start, regardless of the size of
the project.

Of course the action does not touch so many files. It looks like the scanning was still running when you pressed enter.
It waited for the scan is finished. The only solution would be not to generate javadoc skeleton then.

Ok, that might be explanation. 
Although the project was already scanned when it was open (before few hours..) and the scanning indicator in status bar
did not appear. The changes in project were only minor, so there should not be reason for such an extensive scan. 

Tome, any idea why should the scan take so long (~20 s) in a already indexed project? In the snapshot I see that the
java indexer loads some NetBeans projects which takes most of time.

It could be triggered by e.g. updating sources outside the IDE and switching back.

In case you see editor hints or highlighted symbol occurrences in the editor there is no reason why it should take so
long. The file is already parsed and attributed.

Even the up to date check may take long time for api support projects, dependency set up is quite expensive.
GenerateJavadocAction should use Lahvacovo RunOffAWT or runWhenScanFinished (The RunOffAWT is probably much better for hint).

tzezula:
But it is not an editor hint. The user is typing in editor. He types <enter>. We cannot insert anything in background
now. It could result in unwanted mess. Neither RunOffAWT nor runWhenScanFinished are suitable in this case IMO.

Why is it necessary to set up project dependencies or perform the up to date check again? As written above the IDE was
running with the open project for hours.

Some java.source API support which would allow to run over parsed file without waiting for scan would be helpful here.
It should be possible to rewrite the action to use Tree instead of Element.

>Why is it necessary to set up project dependencies or perform the up to date check again? As written above the IDE was
>running with the open project for hours.
Sometimes it's enough that metadata file is touched.

>Some java.source API support which would allow to run over parsed file without waiting for scan would be helpful here.
Yes, it's probably the way we should try. But probably not for 6.8.

Build: NetBeans IDE Dev (Build nbms-and-javadoc-3940-on-090917)
VM: Java HotSpot(TM) Client VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08
OS: Windows XP, 5.1, x86

User Comments: 
the project was scanned again.
it feels like the 'project scanning' is always "in the way"
Maximum slowness yet reported was 21547 ms, average is 12270

Created attachment 88813 [details]
nps snapshot

This issue already has 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=158664

Build: NetBeans IDE Dev (Build nbms-and-javadoc-4040-on-091003)
VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01
OS: Windows XP, 5.1, x86

User Comments: 

Maximum slowness yet reported was 21547 ms, average is 10746

Created attachment 88861 [details]
nps snapshot

This issue already has 6 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=158664

Build: NetBeans IDE Dev (Build 200910061401)
VM: Java HotSpot(TM) 64-Bit Server VM, 14.1-b02, Java(TM) SE Runtime Environment, 1.6.0_15-b03
OS: Linux, 2.6.27.29-0.1-default, amd64

User Comments: 

Maximum slowness yet reported was 131406 ms, average is 27983

Created attachment 88974 [details]
nps snapshot

This issue already has 7 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=158664

*** Issue 164569 has been marked as a duplicate of this issue. ***

Created attachment 92348 [details]
nps snapshot

Editing java files whilst waiting for a query to a large DB table (MySQL) to cancel.

My report, with id #399822, isn't mentioned in this bug.
But it dawned on me that when I insert a /** above a method,
everything below it potentially til the end of the file, is considered
as one giant comment. (No-one else has mentioned this in this bug
it seems).
The most time is spent in javadoc.hints.GenerateJavadocAction.
So presumably it doesn't scale well for very large comments?

Hmm scratch the big-comment idea when I looked at my src it wasn't that big.

Changeset: http://hg.netbeans.org/jet-main/rev/26d18848eb56
Author:    Jan Becicka <jbecicka@netbeans.org>
Date:      2010-10-15 13:37
Message:   Issue #172464 - [69cat] Invoking insert-break took 17927 ms.