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.
Build: NetBeans IDE Dev (Build 090827) 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 Maximum slowness yet reported was 22576 ms, average is 13732
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