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.
Summary: | 4s in directory chooser | ||
---|---|---|---|
Product: | platform | Reporter: | matusdekanek <matusdekanek> |
Component: | Directory Chooser | Assignee: | 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
Created attachment 85312 [details]
nps snapshot
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. 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. 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 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. 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 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. *** 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, 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 Created attachment 87760 [details]
nps snapshot
This issue already has 6 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=154339 Thanks a lot for investigation and the patch, integrated: 0089998c2248 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. |