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.

Bug 169303

Summary: 4s in directory chooser
Product: platform Reporter: matusdekanek <matusdekanek>
Component: Directory ChooserAssignee: David Simonek <dsimonek>
Status: RESOLVED FIXED    
Severity: blocker CC: jtulach, tpavek
Priority: P3 Keywords: PERFORMANCE
Version: 6.x   
Hardware: All   
OS: All   
URL: http://statistics.netbeans.org/exceptions/detail.do?id=154339
Issue Type: DEFECT Exception Reporter: 154339
Attachments: nps snapshot
profiler snapshot for opening the dialog
patch to make sure the tree's row height is > 0
nps snapshot

Description matusdekanek 2009-07-28 11:54:50 UTC
Build: NetBeans IDE Dev (Build 200907280201)
VM: Java HotSpot(TM) Client VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08
OS: Linux, 2.6.28-13-generic, i386

User Comments:
matusdekanek: invoking 'open project' action.


Maximum slowness yet reported was 5227 ms, average is 5227
Comment 1 matusdekanek 2009-07-28 11:54:55 UTC
Created attachment 85312 [details]
nps snapshot
Comment 2 Marian Mirilovic 2009-09-04 10:48:55 UTC
com.sun.java.swing.plaf.gtk.GTKNativeStyle.native_get_xthickness[native]() ... 5 seconds -> GTK ?
Comment 3 Stanislav Aubrecht 2009-09-07 09:32:24 UTC
the delay is reproducible when opening 'open project' dialog window (the first few invocations)
reassigning to project team for evaluation
Comment 4 matusdekanek 2009-09-07 09:42:01 UTC
Created attachment 87202 [details]
profiler snapshot for opening the dialog
Comment 5 Milan Kubec 2009-09-07 14:37:03 UTC
Reassigning to performance for evaluation, it looks that JFileChooser has been opened. Thanks.
Comment 6 Jaroslav Tulach 2009-09-11 13:31:39 UTC
The snapshot 
http://www.netbeans.org/nonav/issues/showattachment.cgi/87202/openProjectDialogSlowness.nps
shows that the directory chooser asks a lot of times (more than 40) about status of some files. It is probably 
unnecessary. I suggest to replace the VariableLayoutCache with FixedHeightLayoutCache or somehow limit the number of 
queries.
Comment 7 David Simonek 2009-09-11 13:55:33 UTC
I don't understand the hint from performance team. Directory chooser have to ask for files because it's his job. It
doesn't make sense. Are there any user reports that directory chooser is slow? If not, then this issue is just a waste
of time. Passing back to performance team, as I don't know what you are asking for and why. What a change in behavior of
performance team, different when I was on the board, that's sad...
Comment 8 Jaroslav Tulach 2009-09-11 15:39:23 UTC
You have full right to believe that this issue is waste of time. But it clearly belongs to directory chooser, so I 
would ask you to not mangle with component and subcomponent fields. Thanks.

As the advice goes. You are said to know more about swing than us, so I would expect you to know that performance of 
VariableLayoutCache is not really good when displaying large trees. Why? Because it needs to ask each visible node for 
its size. The snapshot 
http://www.netbeans.org/nonav/issues/showattachment.cgi/87202/openProjectDialogSlowness.nps
indicates that this is the problem in this case. FixedHeightLayoutCache would not suffer from this problem, as it asks 
just one node for its size (e.g also icon).

The final shape of the fix is indeed in your hands.
Comment 9 David Simonek 2009-09-11 16:03:33 UTC
No, you are wrong,  I know nothing about VariableLayoutCache and FixedHeightLayoutCache, to please take back your
assumptions. As you failed to show me user reports and I don't know what to do with this issue, I'm closing. And I need
to repeat: What a change in behavior of performance team, different when I was on the board, that's sad...
Comment 10 Tomas Pavek 2009-09-14 15:06:17 UTC
There's still something suspicious on this issue. Here's what I've found. I'm reopening so you can consider it, or close
again.

The use of fixed row height (instead of variable) in large trees is something very obvious, so I wondered if we really
would not make such optimization already. And indeed, there is issue 127170 - which was fixed by setting "large model"
optimizations on the tree in the directory chooser. See in DirectoryChooserUI how the JTree is created with overriden
isLargeModel() method to always return true.

Now if you look at BasicTreeUI.createLayoutCache method, it always creates FixedHeightLayoutCache if the tree has large
model. I have even put a breakpoint in BasicTreeUI.setModel to see what layout cache is there (field 'treeState') and
indeed it was FixedHeightLayoutCache. The strange thing is that the profiler snapshot clearly shows there was
VariableHeightLayoutCache when the execution went through this point.

That would mean the optimization (which was found desirable and implemented time ago) may not work in some cases.
Perhaps the createLayoutCache behaves differently in GTK L&F's tree UI? Could you check it? It's ok on Windows for me -
but the report came from Linux. So I thought it might be worth checking this on Linux. Thanks.
Comment 11 Tomas Pavek 2009-09-15 11:05:26 UTC
*** Issue 169284 has been marked as a duplicate of this issue. ***
Comment 12 Tomas Pavek 2009-09-15 11:07:26 UTC
Issue 169284 contains 4 more reports of the same kind.
Comment 13 Tomas Pavek 2009-09-15 11:14:36 UTC
I have found the cause. The fixed height cache also requires the tree to have a non-zero row height, but GTK and Nimbus
L&F have 0 (or -1) in their defaults which is set during JTree instantiation. It is changed later but it's there at the
moment the BasicTreeUI creates the cache, so it then does not work in the "large model" mode. Since the tree used in
DirectoryChooserUI sets an explicit row height later, I think it's safe to ignore setting a row height that is <= 0.
I've verified it fixes the problem on Nimbus L&F. Attaching patch.
Comment 14 Tomas Pavek 2009-09-15 11:16:05 UTC
Created attachment 87675 [details]
patch to make sure the tree's row height is > 0
Comment 15 Jaroslav Tulach 2009-09-16 07:20:57 UTC
*** Issue 150013 has been marked as a duplicate of this issue. ***
Comment 16 Exceptions Reporter 2009-09-16 12:54:33 UTC
Build: NetBeans IDE Dev (Build 200909140908)
VM: Java HotSpot(TM) 64-Bit Server VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08
OS: Linux, 2.6.27.30-170.2.82.fc10.x86_64, amd64

User Comments: 
invoked Open Project
Maximum slowness yet reported was 25334 ms, average is 8329
Comment 17 Exceptions Reporter 2009-09-16 12:54:43 UTC
Created attachment 87760 [details]
nps snapshot
Comment 18 Exceptions Reporter 2009-09-16 12:55:18 UTC
This issue already has 6 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=154339
Comment 19 David Simonek 2009-09-17 15:39:03 UTC
Thanks a lot for investigation and the patch, integrated:
0089998c2248
Comment 20 David Simonek 2009-09-17 16:03:49 UTC
Btw, I apologize for my somewhat emotional comments above. jtulach kindly came to me to discuss and I made my position
more clear without unneeded emotions.

My feeling is that performance team should give patches where it's reasonable or doable, like in this example, thanks
for that. 

But real primary roots of my negative emotions are:
- that automated process of "slowness detector" is in my eyes outsourcing the work of performance team to all
developers, bugs from the process can go to the developers totally unmoderated
- that automated process is indirectly giving me work orders. I will never accept to be managed by a machine and I will
always have negative feelings about that, and, sadly, as I'm human, also about the authors of such system, sorry.