sun.awt.shell.Win32ShellFolder2.hasAttribute(int) - dominates JFileChooser init>

Performance Tuning
#1

Not exactly game related, but I was looking into a problem with a preference dialog in my application taking a long time to come up after the user selected the menu item. At the moment I construct the UI panels and dialog every time the preference option is selected. Part of the preference panels construct JFileChoosers to be shown later if the user hits a browse button to change some config files. The JFileChooser is constructed but never shown.

When using NB 5 RC2 Profiler to profile the construction of my preference UI the method “sun.awt.shell.Win32ShellFolder2.hasAttribute(int)” takes 55% of the time! It is invoked 6030 times! Taking a total of just over 2 seconds according to the profiler!

What the heck is going on? 6030 invocations??? The actual number of files that the JFileChooser would even need to “look at” (even though it has no reason I can think of for scanning anything on the file system until it is actually shown) would be less than one tenth of that number.

Maybe I have 8 JFileChoosers as sun.awt.shell.Win32ShellFolder2.listFiles is invoked 8 times. 6030/8 = 754 but there are WAY less than 754 files “visible” to these JFileChoosers as far as i can tell - it would be more like 150 files when the JFileChooser is first constructed, then 3 or 4 files if the ‘current folder’ is changed during the initialization of the UI. So even if I give it 160 files * 8 JFileChoosers that would be 1280 files to ‘examine’.

This is all tested with Java 6 b68. I know they’ve been working to improve JFileChooser in Java 6… and I thank Sun for the (long overdue) effort… but the bloody thing still sucks chunks, on windows at least. We’ve had numerous complaints about the file chooser from our customers.

#2

Ah it seems this is Bug 6372808

Though there are many performance related bugs for JFileChooser… many of them marked closed or duplicate where it seems the performance issue was never properly dealt with.

#3

Hehe ! I reported issues regarding slow realization of JFileChooser and JColorChooser way back in May 2004 :o ! Dunno if the present problems are related, but my guess is that the mess started when I shifted from Win 98 to Win XP.

My posts to Scott Violet at the Swing forum:
http://www.javadesktop.org/forums/thread.jspa?forumID=2&threadID=2441&messageID=10832#10832

And at the Java 3D forum - Java 3D seems to aggravate these issues:
http://www.javadesktop.org/forums/thread.jspa?forumID=55&threadID=4131&messageID=22909#22909

And the funny problem with the NetBeans profiler is that my Java 3D app. hangs up when I click on a JMenuItem to display the JFileChooser. This used to be the case with NetBeans 4.1 and profilers pre 9 IIRC. With RC1 and the latest profiler my app. doesn’t even get launched, not to speak of trying to display a JFileChooser :frowning: ! The Thread Monitoring profiler task seems to be the only one that works !

My practice to stay out of trouble, as mentioned in the above threads, is to precreate and cache all JFileChoosers and JColorChoosers. Yuck !

#4

[quote=“NVaidya,post:3,topic:25963”]
I’m basically doing something along those lines… where I can. To avoid massively slow startup that this causes I do lazy initialization in some spots.

The sad thing is that Java should be FASTER than the Windows dialog… since the Windows code for explorer.exe is so horribly inefficient! It’s not like JFileChooser actually supports the appropriate shell extensions to make the look match the native look (e.g. icon overlays, full context menu, etc), so ultimately it should be doing less work.

#5

BTW, thanks very much initiating this thread and for the link to Bug 6372808. Looks like the issues may not be anything peculier to Java 3D and, specifically, my app.

#6

No problem… now lets get some votes for that bug :slight_smile: !

I’d email Scott Violet directly… but I don’t want to irritate the Sun engineers :slight_smile: better save that for when I have something more to offer.

I’m toying with the idea of getting set up to build Mustang… but the chatter I’m seeing suggests it’s pretty late in the game for them to integrate outside code for the first release.

The performance is just sooo bad though. I know that quite literally my company has lost customers over issues with JFileChooser. First it was the sorting in details view (that Sun would not even acknowledge as a bug in the Windows look and feel - they call it a feature request!)… That’s been fixed for Mustang finally (thanks guys), and I know they are at least trying to pay attention to some other look and feel fidelity issues… but the performance problem has been downplayed for so long… it’s like they don’t believe it’s there… if yousearch the bug database for JFileChooser perfomance issues you will see tons of examples… marked duplicates where they probably should be, then the duplicate get marked as could not reproduce, and it’s all just washed under the table like nothing ever happened.

I saw one bug marked closed that indicated some new bindings to Win32 shell functions in Mustang were going to fix the performance… but many builds after that “fix” the performance is still unacceptable.

On one hand we want to be as cross-platform ready as possible, on the other I’m getting lots of flack because of issues like this. At our weekly status meetings you should see the looks I get if I say I’ve upgraded the JRE for the next build… most of the people in the room take it as a sign of trouble. We’ve been burned by performance issues in the JRE before - with an indeterminant progress bar generating garbage very fast, then the GC kicked in at such a high thread priority that it starved device drivers and our video capture application drops frames. Customers expect it to run 24/7 to stream TV channels or archive TV broadcasts… they get mad when the system locks up in a few hours and it’s all because of something horribly wrong in the JRE that wasn’t like that in the last version.

Now we have some long awaited fixes coming in Mustang, but they’ve lost confidence, and if it only fixes half the bugs, they will think, “here we go again, another year and a half to wait before anything gets done about it.” Then the “why aren’t you using .Net?” questions start and we have to point out why we don’t want to use .Net even though it will solve these issues (on Windows).

Can you tell it’s stressing me out? :slight_smile:

#7

Performance fixes (especially contributed ones) have a high priority. So if you do
come up with the fix, there’s a good chance it will be allowed into mustang (assuming it’s
not too risky).

I think you can email Scott as well… He doesn’t bite. Most of the time…

Thanks,
Dmitri

#8

Do you have a small and self-contained test case which demonstrates the problem? Is the directory you’re working with on the local disk or over a network?

A significant amount of performance work went into the JFileChooser back in 1.4.2 but I personally don’t know the state of the code at this point. My own impression from using it day-to-day has been that it’s reasonably fast and usually better performing than other custom file choosers like Mozilla’s file chooser.

#9

There is test code in the bug report. I’m VERY surprised that anyone that has used a JFileChooser with the Windows LaF wouldn’t be painfully aware of this issue. All the people I have talked to all know the workaround of caching JFileChoosers and only creating them if absolutely necessary. Nobody I have been in contact with considers the performance of JFileChooser acceptable.

Perhaps people don’t set the look and feel to the platform native look and feel often enough?

import javax.swing.JFileChooser;
import javax.swing.UIManager;
import javax.swing.UnsupportedLookAndFeelException;

public class JFCTest
{
    public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException, UnsupportedLookAndFeelException
    {
        UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
        long before = System.currentTimeMillis();
        new JFileChooser();
        System.out.println("JFileChooser construction took "+(System.currentTimeMillis()-before)+" ms");
    }
}

The first time I tried the above code it took over 4.5 seconds to construct the JFileChooser… subsequent tries were just over 1.1 seconds (blazing!). Commenting out the setting of the LaF saves me 300ms - it’s still extremely slow… but better. Thats with Mustang b68.

Trying with Java 5 (1.5.0_06) the first attempt was 3.8 seconds, followed by 1.3 seconds for subsequent tries.

Now replace the JFileChooser with the java.awt.FileDialog (you’ll need a Frame for the parent). Time to construct an AWT FileDialog - ZERO milliseconds… i.e. fast enough that I can’t measure it with currentTimeMillis()… using nanoTime it came out to 1.25 milliseconds. That was still Java 5… Mustang b68 takes closer to 1 ms.
It is ONE THOUSAND times faster to construct an AWT FileDialog than constructing a JFileChooser. :frowning:

The machine is on a LAN and it has networked drives… but I’m running this from the C: drive and can’t think of any reason that the network drives would be accessed. Even explicitly passing a local path to an EMPTY folder the performance is still just as bad.

If you delay the JFileChooser construction to when the user actually hits a load/save/browse button of some sort… you still get over one second of delay at least before the user sees a reaction. Every Java program using JFileChooser that tries to integrate with the Windows LaF gets a horrible reputation because this is such a common user experience.

Even worse, think of the seconds that pile up if you have just a few JFileChoosers that get constructed for some UI panel. I have several cases where the panel contains several instances of a helper object I’ve made called PathField - a text feld with a browse button. Sometimes I can delay the construction of the JFileChooser, other times it is much more convenient to create it and initialize various aspects of the JFileChooser prior to the user hitting the browse button.

These measurements on a machine that is not exhibiting another phenomena that makes the JFileChooser construction closer to the 5-10 second range (with similar times to change directories after the JFileCooser is shown). We still haven’t been able to identify what makes that ultra slow construction speed up to just the extremely slow construction - it might be related to the machines network configuration.