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
matusdekanek: invoking 'open project' action.
Maximum slowness yet reported was 5227 ms, average is 5227
Created attachment 85312 [details]
com.sun.java.swing.plaf.gtk.GTKNativeStyle.native_get_xthickness[native]() ... 5 seconds -> GTK ?
the delay is reproducible when opening 'open project' dialog window (the first few invocations)
reassigning to project team for evaluation
Created attachment 87202 [details]
profiler snapshot for opening the dialog
Reassigning to performance for evaluation, it looks that JFileChooser has been opened. Thanks.
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
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...
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
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.
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...
There's still something suspicious on this issue. Here's what I've found. I'm reopening so you can consider it, or close
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.
*** Issue 169284 has been marked as a duplicate of this issue. ***
Issue 169284 contains 4 more reports of the same kind.
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.
Created attachment 87675 [details]
patch to make sure the tree's row height is > 0
*** Issue 150013 has been marked as a duplicate of this issue. ***
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, 184.108.40.206-170.2.82.fc10.x86_64, amd64
invoked Open Project
Maximum slowness yet reported was 25334 ms, average is 8329
Created attachment 87760 [details]
This issue already has 6 duplicates
Thanks a lot for investigation and the patch, integrated:
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
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.