Bug 171713 - Introduce asynchronousOpen() to eliminate 22s freeze
Introduce asynchronousOpen() to eliminate 22s freeze
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Text
6.x
All All
: P2 (vote)
: 6.x
Assigned To: mslama
issues@platform
http://statistics.netbeans.org/except...
EXCEPTIONS_REPORT perf-profileme
: API_REVIEW_FAST, PERFORMANCE
: 172461 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-08 13:48 UTC by Jaroslav Tulach
Modified: 2009-11-10 17:11 UTC (History)
15 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
nps snapshot (27.37 KB, bin/nps)
2009-09-08 13:48 UTC, Jaroslav Tulach
Details
nps snapshot (55.97 KB, bin/nps)
2009-09-29 11:56 UTC, Jaroslav Tulach
Details
nps snapshot (62.63 KB, bin/nps)
2009-10-01 04:47 UTC, Jaroslav Tulach
Details
nps snapshot (44.75 KB, bin/nps)
2009-10-01 21:16 UTC, _ tboudreau
Details
Patch for openide.text (14.35 KB, text/plain)
2009-10-02 11:32 UTC, mslama
Details
Patch with proposed changes (47.59 KB, text/plain)
2009-10-07 14:20 UTC, mslama
Details
nps snapshot (12.72 KB, bin/nps)
2009-10-07 14:48 UTC, iceman81
Details
Patch for Y03-Y05 (47.95 KB, text/plain)
2009-10-08 11:15 UTC, mslama
Details
nps snapshot (256.00 KB, application/nps)
2009-11-10 17:11 UTC, widipa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2009-09-08 13:48:34 UTC
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
Comment 1 Jaroslav Tulach 2009-09-08 13:48:38 UTC
Created attachment 87271 [details]
nps snapshot
Comment 2 David Strupl 2009-09-16 14:00:25 UTC
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.
Comment 3 mslama 2009-09-16 14:25:09 UTC
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?
Comment 4 Tomas Hurka 2009-09-16 15:31:57 UTC
thread "org.openide.text Document Processing"  is masked as 
"Inactive RequestProcessor thread [Was:Timeable Event Queue Watch Dog/org.netbeans.core.TimableEventQueue]"
Comment 5 rmichalsky 2009-09-18 09:43:49 UTC
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.
Comment 6 Jaroslav Tulach 2009-09-18 10:19:58 UTC
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.
Comment 7 mslama 2009-09-21 14:59:35 UTC
*** Issue 172461 has been marked as a duplicate of this issue. ***
Comment 8 Exceptions Reporter 2009-09-21 16:36:56 UTC
This issue already has 8 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 9 Exceptions Reporter 2009-09-23 14:52:18 UTC
This issue already has 9 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 10 Exceptions Reporter 2009-09-25 23:35:35 UTC
This issue already has 10 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 11 Jaroslav Tulach 2009-09-29 11:56:39 UTC
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
Comment 12 Jaroslav Tulach 2009-09-29 11:56:44 UTC
Created attachment 88507 [details]
nps snapshot
Comment 13 Exceptions Reporter 2009-09-29 11:56:49 UTC
This issue already has 11 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 14 Exceptions Reporter 2009-09-29 15:34:53 UTC
This issue already has 12 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 15 Exceptions Reporter 2009-09-29 19:53:02 UTC
This issue already has 13 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 16 misterm 2009-09-29 19:59:19 UTC
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).
Comment 17 Exceptions Reporter 2009-09-30 09:06:27 UTC
This issue already has 14 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 18 Jaroslav Tulach 2009-10-01 04:47:49 UTC
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
Comment 19 Jaroslav Tulach 2009-10-01 04:47:54 UTC
Created attachment 88637 [details]
nps snapshot
Comment 20 _ tboudreau 2009-10-01 21:15:55 UTC
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
Comment 21 _ tboudreau 2009-10-01 21:16:02 UTC
Created attachment 88698 [details]
nps snapshot
Comment 22 Exceptions Reporter 2009-10-01 21:16:08 UTC
This issue already has 20 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 23 mslama 2009-10-02 11:32:44 UTC
Created attachment 88729 [details]
Patch for openide.text
Comment 24 mslama 2009-10-02 11:35:57 UTC
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.
Comment 25 Jaroslav Tulach 2009-10-04 07:45:55 UTC
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 
Comment 26 Jaroslav Tulach 2009-10-04 19:07:40 UTC
Y03 Print warning when the method is not overriden (either to return true or false, but overriden) and print the name 
of violating subclass.
Comment 27 Exceptions Reporter 2009-10-05 09:06:25 UTC
This issue already has 21 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 28 Exceptions Reporter 2009-10-05 10:01:46 UTC
This issue already has 22 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=155933
Comment 29 mslama 2009-10-07 14:20:18 UTC
Created attachment 89010 [details]
Patch with proposed changes
Comment 30 iceman81 2009-10-07 14:48:12 UTC
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
Comment 31 iceman81 2009-10-07 14:48:19 UTC
Created attachment 89016 [details]
nps snapshot
Comment 32 Jaroslav Tulach 2009-10-07 15:35:03 UTC
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

Comment 34 mslama 2009-10-08 11:15:58 UTC
Created attachment 89085 [details]
Patch for Y03-Y05
Comment 35 mslama 2009-10-09 12:29:16 UTC
jet-main #b4dd900f3229
Comment 36 mslama 2009-10-09 12:29:34 UTC
Fixed
Comment 37 Quality Engineering 2009-10-14 11:03:18 UTC
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.
Comment 38 Jesse Glick 2009-10-14 16:57:04 UTC
Backing out due to unresolved test failures: core-main #9afb0eccbf82

Also possibly cause of deadlock in issue #174564.
Comment 39 Quality Engineering 2009-10-15 10:25:10 UTC
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.
Comment 40 Jaroslav Tulach 2009-10-15 11:45:54 UTC
Another try: core-main#1f650edec019
Comment 41 _ tboudreau 2009-10-15 16:03:54 UTC
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. 
Comment 42 mslama 2009-10-15 16:53:19 UTC
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.
Comment 43 _ tboudreau 2009-10-15 17:03:47 UTC
> 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.
Comment 44 Jaroslav Tulach 2009-10-16 08:13:10 UTC
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.
Comment 45 widipa 2009-11-10 17:11:10 UTC
Created attachment 90754 [details]
nps snapshot


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo