Bug 30014

Created attachment 8549 [details]
Simple patch

There is another performance issue , related to expanding folders in
the filesystems view , see issue 27777

See also issue #29828 for the performance test

Created attachment 8726 [details]
optimizeIt export about refreshChildren called by open folder

Created attachment 8727 [details]
export from optimizeIt about AWT thread called by open folder

Created attachment 8728 [details]
optimizeIt export about refreshChildren called by open folder with java nodes

Created attachment 8729 [details]
export from optimizeIt about AWT thread called by open folder with java nodes

Observation (measured by optimizeit) the first open a folder with 15
java files.

- takes 6360ms, the interesting threads:

CPU usage for thread Folder recognizer
- The considerable time takes (64%, see java_folders_parse,html) the
java parser, which computes immediately at open folder. If the parsing
is disabled then open takes only 2720ms.
==> I propose disable "auto prescan files" action by default (this
action runs the java parser)

CPU usage for thread AWT-EventQueue-0
- takes 5210ms
- painting tree takes 29% (1555ms, see java_folders_AWT.html)
- FilterNode.getIcon() takes 2221ms (42%), i.e. for each file twice
runs JavaDataObject.getCompilerType(), 39%

Observation (measured by optimizeit) the first open a folder with 1001
folders

- takes 21300ms, the interesting threads:
CPU usage for thread FolderChildren_refresher (see 1000folders.html)
There are tree parts divided each by about 30% of time.
- 30.4% org.openide.nodes.Node.addNodeListener() takes 6190ms, the
listener is added for each subfolder (1001 inv), the adding listener
initializes node lookup (all results are asked)
- 30.95% - 6600ms - Children$Keys.setKeys()
- 29.63% - 6300ms - DataFolder.getClonedNodeDelegate(), called for
each subfolder, getting cloned delegate consist from
DF.createNodeDelegate (20%) and init DF$ClonedFilter

CPU usage for thread AWT-EventQueue-0 (see 1000folders-AWT.html)
- takes 6220ms
- the considerable time takes (38%, 2400ms) computing node dimension
which contains getting cell rendered component and getting preferred size.
-- NodeRenderer.getTreeCellRendererComponent (23%, invoked for each
subfolder), this getter asks an icon (8%) and display name (6.5%)
-- computing preferred size (11%)
- the rest is only swing painting

The count of subfolders was exaggerative, I haven't known any part of
code to improving speed. To improve responsiveness I propose use an
wait cursor for expanding folder and delay add the nodes to all
children are calculated.

Tomasi, pls attach the diffs of patches of JavaSettings, the disabling
of java parser, etc. The caching of compiler type considerable speed
up open folder. Thanks

Created attachment 8772 [details]
Proposed patch for java module.

There was similar discussion about expanding of folders:
http://www.netbeans.org/servlets/ReadMsg?
msgId=440218&listName=nbui

Result was displaying please wait text and wait cursor 
during expansion.

Created attachment 8793 [details]
Improved version of java-module patch

Created attachment 8801 [details]
adding wait cursor on expand folder

I added the patch which enabled the progress cursor when a folder was
being expanded; the normal cursor was set back at the end of
initialization of folder children.

The waitCursor.diff sneaks in a private API contract between Nodes,
DataSystem and Explorer. It could be a solution of last chance if
there would be no other possiblity, but I still would request
documentation and tests before it gets into codebase.

Thus consider another alternative: There already is a contract with
Nodes to obtain full set of nodes children. Just call

node.getChildren ().getNodes (true);

So just implement this method properly in FolderChildren (not hard,
findChild already does the computation anyway) and use it in explorer
to find out where the computation of nodes is over.

Yardo, good remark. I think so that using Children.getNodes(true) is
cleaner then using undocumented property. I filed the issue 30680 to
FolderChildren for correctly execute getNodes(true). I prepare
behavior progress cursor with this contract.

Created attachment 8814 [details]
proposed patch uses getChildren().getNodes(true)

The attached patch progressCursorWithGetNodes.diff uses
getChildren().getNodes(true) as Yarda recommends. A side effect (I
think it's correct) is that the progress cursor is showed on the all
types of nodes not only on a folder node. The cursor shows in all
cases even thought for a quick time. Optionally we can wait for any
given time before the cursor will showed, it could be solved
asynchrony with this issue. I'm going to apply the patch (tomorrow)
Feb 06 if no veto.

If the progress cursor doesn't stay "on" during the entire node
expansion, it will be misleading to the user.  In my closed source
module I'm using a Children subclass's addNotify() to both set and
unset the progress cursor and this is working fine.  If a module does
long-running work before addNotify() is called, then the progress
cursor won't be set early enough.  I had that problem but fixed it.  I
think that we need a solution that will set the progress cursor at the
beginning of node expansion and unset it only when all the children
are visually present, not sooner or later.  If it relies on timed
delays there could be problems.  I suggest that you test your patch on
J2EE nodes and Data Folders containing J2EE nodes from S1S to be sure
that the progress cursor is shown for the correct duration.  If it
doesn't, then I would consider it a bug.

Another issue related to this is Dusan's comment on 2003-02-04 about
also setting a temporary "Please Wait..." node, like the Java module
does.  Is this part of your integration? If so, I have a closed source
module that is already setting this temporary wait node in its
Children subclass in addNotify(), and I would need to remove my code. 

I like it - seems to work fine on my computer.

To Jeri: The progress cursor will be managed by TreeView, you can
remove your cursor from your code. It will be work for all nodes as
general. The "Please-wait" node is not planned for all types nodes,
each implementation of Children can decide if the Please-wait node
show or not. For example FolderChildren should provide it. Your code
about Please-wait node shouldn't be affected by this change.

Resolved. Summary:
- the performance of FolderChildren (issue 30657) was considerable
improved (in my test case, 1000 subfolders from 8700ms to
4700ms/3750ms), issue is still open for next optionally speed-up
- the performance of recognizing java sources in a folder was improved
(in my test case from 8200ms to 7200ms), the issue for more possible
improvement was filed (see issue 30775)
- the progress cursor is showed when any node is being opened
- Please-wait node can be showed by decision of specific Children
implementation, FolderChildern should show it, also FolderChildren
should return all children at once (tracked by issue 30772)

verified...

x