Bug 171713

Created attachment 87271 [details]
nps snapshot

The .nps snapshot is showing that Jarda's computer was waiting 17s for one invocation of
java.io.UnixFileSystem.getLastModifiedTime [native]
and it get there via apisupport. Please check and possibly close as INVALID as there might not be a way how to make that
faster.

I still do not see why AWT is blocked. There should be thread "org.openide.text Document Processing" which is actually
loading document and AWT should be waiting for this thread. But I do not see it in snapshot. Thread "Java Node Badge
Processor" is independent on this IMO. Jarda, Tomas any comment why thread "org.openide.text Document Processing" is not
shown in snapshot?

Should CloneableEditorSupport.open() be called from AWT thread?

thread "org.openide.text Document Processing"  is masked as 
"Inactive RequestProcessor thread [Was:Timeable Event Queue Watch Dog/org.netbeans.core.TimableEventQueue]"

This could be resolved by issue #169040 (by not blocking property evaluation), but only since code in document
processing asks for potentially "fast" property ${javac.source} and not for e.g. ${module.classpath}. 

So could be document processing changed not to block AWT thread? What is the point of doing it in bg thread when it
blocks UI anyway? It could resolve many similar problems. If there are reasons why UI must be blocked, I'll mark this
issue as WONTFIX.

OK, so the summary is:
1. AWT thread needs instance of Document.
2. background thread creates the Document, but then also feeds its content
3. feeding content takes too much time as it queries apisupport project settings

The easiest way to speed this up is to let AWT thread to get an instance of document without waiting for it to be 
loaded. That would require CloneableEditorSupport to have (internally) a method like Document openDocument(boolean 
loaded=false). Reassigning to Marek. We can discuss details on Monday.

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

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

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

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

Build: NetBeans IDE Dev (Build 090914)
VM: Java HotSpot(TM) Client VM, 14.1-b02, Java(TM) SE Runtime Environment, 1.6.0_15-b03
OS: Linux, 2.6.29.6-desktop-1mnb, i386

User Comments: 

Maximum slowness yet reported was 100362 ms, average is 19512

Created attachment 88507 [details]
nps snapshot

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

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

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

In my case, no --open option was specified in the command line. There were just a bunch of editor windows opened from the 
last session that needed to be restored (which probably has the same effect).

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

Build: NetBeans IDE Dev (Build 090911)
VM: Java HotSpot(TM) Client VM, 14.1-b02, Java(TM) SE Runtime Environment, 1.6.0_15-b03
OS: Linux, 2.6.24.7-laptop-1mnb, i386

User Comments: 

Maximum slowness yet reported was 100362 ms, average is 15998

Created attachment 88637 [details]
nps snapshot

Build: NetBeans IDE Dev (Build 200909221401)
VM: Java HotSpot(TM) 64-Bit Server VM, 11.3-b02-83, Java(TM) SE Runtime Environment, 1.6.0_13-b03-211
OS: Mac OS X, 10.5.7, x86_64

User Comments: 
Restarted NetBeans
Maximum slowness yet reported was 100362 ms, average is 16794

Created attachment 88698 [details]
nps snapshot

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

Created attachment 88729 [details]
Patch for openide.text

Method asynchronousOpen is overwritten for default support eg. txt files and for java files. If no problems will appear
we can change it for more subclasses.

Y01 Please duplicate some tests (for sure some that deal with UserQuestionException) to also use CES with 
asynchronousOpen() { return true }

Y02 Write a test to show that open finishes, CloneableEditor is shown in spite some kit's load method is waiting 
indefinitely 

Y03 Print warning when the method is not overriden (either to return true or false, but overriden) and print the name 
of violating subclass.

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

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

Created attachment 89010 [details]
Patch with proposed changes

Build: NetBeans IDE Dev (Build 200910010513)
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 100362 ms, average is 14908

Created attachment 89016 [details]
nps snapshot

Re. Y03 minor: Preferably use some Logger from org.openide.text package. Also you could include some link (possibly to 
apichanges document's entry) into the report so people know what they shall do.

Y04 Missing @since
Y05 @return could say that default version returns false and prints a warning

Re Y03: Do you mean to add link
http://bits.netbeans.org/dev/javadoc/org-openide-text/apichanges.html#CloneableEditorSupport.asynchronousOpen to warning?

Created attachment 89085 [details]
Patch for Y03-Y05

jet-main #b4dd900f3229

Fixed

Integrated into 'main-golden', will be available in build *200910140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/b4dd900f3229
User: Marek Slama <mslama@netbeans.org>
Log: #171713: Add CloneableEditorSupport.asynchronousOpen to control if CloneableEditorSupport.open loads document synchronously or not.

Backing out due to unresolved test failures: core-main #9afb0eccbf82

Also possibly cause of deadlock in issue #174564.

Integrated into 'main-golden', will be available in build *200910150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/9afb0eccbf82
User: Jesse Glick <jglick@netbeans.org>
Log: Backed out changeset b4dd900f3229
#171713 caused unresolved test regressions.

Another try: core-main#1f650edec019

If you want to do this sort of asynchronous loading, wouldn't it make more sense to do it at the window system level?  I.e. instead of deserializing 
TopComponents (maybe create empty-panel placeholder TopComponents that have the right ID and can replace themselves on componentShown() to answer 
TC.R.getOpened() queries), delay that, loading the actual data asynchronously (possibly some optimizations can be done if using @ConvertAsProperties) - and 
give TC's the opportunity to participate in loading (so what you are doing here can be done in a background thread, but the TC does not have to worry about 
the threading code to do it).  Note o.n.swing.tabcontrol.TabbedContainer has built-ins support for really instantiating tab contents only the first time it is 
switched to.

Seems like that would solve the problem for all components, not just Java editors, and probably be more maintainable. 

Tim it is about asynchronous loading of document ie. it is specific to editors. Nothing to do at winsys level IMO. In
addition CloneableEditor initialization is 2 stage. First something is done in private RP and then second 'visual' or
'Swing' work is done in AWT. I do not know if there is any other TC use case which could use it. In such case we could
consider to implement something similar in winsys.

> First something is done in private RP and then second 'visual' or 'Swing' work is done in AWT. I do not know if there is any other TC use case which could 
use it.

Yes, I know how it works.

> I do not know if there is any other TC use case which could use it. In such case we could consider to implement something similar in winsys.

Probably startup performance in general would benefit.  And if there is asynchronous load support in the window system, then you can delete the 
background thread stuff for editors and just hang the background work off of the new asynchronous loading support in the window system.  That way it 
does not have to be written on a case-by-case basis for every editor that needs it.  And as a side effect, it should be possible to transparently load the 
entire window system on restart, but only actually read winsys data for components that are showing.  Should work for any TC that uses Externalizable to 
save its data (i.e. doesn't want to deserialize a Swing component).  The only thing that would break is if someone assumes they can look up a TC by ID and 
then cast it to an instance type.

The point is, this sort of asynchronous thing will be copy/pasted all over the place - we have plenty of cases where components implement their own lazy 
loading strategies.  That seems like a good argument for directly supporting asynch initialization in the window system (which will have benefits for other 
components) and not doing it at the text editor level.

Having windowsystem to quickly load all modes and names of TopComponents and only later deal with the content would be 
nice. Anyway the discussion belongs elsewhere, not into IZ.

Created attachment 90754 [details]
nps snapshot