Skip to main content

JFileChooser performance in b98

10 replies [Last post]
wgradkowski
Offline
Joined: 2005-08-14
Points: 0

Hi,

JFileChooser on Windows still has poor performance. The situation is: I have a data set of medical images. The file structure is like this:

<br />
+main_image_dir<br />
   + image_dir_1<br />
   + image_dir_2<br />
   (...)<br />
   + image_dir_5<br />
       + image_file_1<br />
       + image_file_2<br />
       (...)<br />
       + image_file_10000<br />

so there is a "main image dir" that has a few (1-10) "image dirs", where each one of them keeps a large number of files" (>3000).

The moment where JFileChooser is blocked for several seconds is when changing directory from top to "main image dir". Then entering each of "image dir" works smooth. Moreover when you traverse up in the directory tree and enter the very same directory again ("main image dir") there's no lag - looks like JFCh caches it somewhere.

The lag of JFileChooser is enormous in comparison to native file dialog. I've seen that the problem is marked as fixed (JFileChooser performance), but apparently not in this situation.

I hope JFileChooser team will work on that one day :)

Cheers

/w.

Message was edited by: wgradkowski

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tackline
Offline
Joined: 2003-06-19
Points: 0

> I have. The e-mail from Sun: "We currently have a
> three week average response time". I'll wait and see
> ;)

It seems to have had that message since about 1996...

I have had response times ranging from six hours to years.

wgradkowski
Offline
Joined: 2005-08-14
Points: 0

>
> It seems to have had that message since about
> 1996...
>
> I have had response times ranging from six hours to
> years.

yes... I know that JFileChooser has problems since forever, but actually Sun accepted it as a [b]new[/b] bug. You will be able to track it here:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6468222

once it appears in the public data base (according to Sun 1-2 days). Try voting for it :) Maybe in next 2 years when JDK 7 is released this issue will be fixed ;)

Cheers.

/w.

swpalmer
Offline
Joined: 2003-06-10
Points: 0

Why is this a NEW bug? There is already more than one bug in the database about how pathetically slow JFileChooser is (you don't even need to show it, just constructing a JFileChooser can be the bottleneck in an application).

Note also that Windows Explorer itself has similarly strange delays, but it is in general an order of magnitude faster. Windows itself appears to scan one level too deep when displaying a directory. Even though no information from the deeper levels is visible the number of file objects in the next level deep seems to be a significant factor is slowing down the native windows file browser/explorer. Could this be a side effect in JFileChooser that just shows up easier because JFileChooser is so much slower in general?

mthornton
Offline
Joined: 2003-06-10
Points: 0

In some views (e.g. thumbnails) the native explorer shows information from child directories. Perhaps it collects this information regardless of the current view. It also has a bit of work to do in determining the correct icon for each file. ZIP files seem to be another factor in slow performance --- again it seems to be looking within the file.

swpalmer
Offline
Joined: 2003-06-10
Points: 0

> In some views (e.g. thumbnails) the native explorer
> shows information from child directories. Perhaps it
> collects this information regardless of the current
> view.

That's my assumption as well. It can be very irritating when browsing a slow, network-based directory and the view doesn't need any of that information from deeper levels.

Of course JFileChooser doesn't even support the Thumbnails view at all (that's another bug with the Windows LnF) so why would it have even worse performance issues?

sjasja
Offline
Joined: 2004-08-15
Points: 0

The slowness appears to come from method isDirectory() in Win32ShellFolder2. isDirectory() calls hasAttribute(ATTRIB_HASSUBFOLDER) which takes a few dozen milliseconds in a folder that has thousands of files. If lots of directories are listed those milliseconds add up.

A quick hack is to reverse the two hasAttribute() calls in isDirectory: instead of
[pre]
if ((hasAttribute(ATTRIB_HASSUBFOLDER) || hasAttribute(ATTRIB_FOLDER))
[/pre]
do this
[pre]
if ((hasAttribute(ATTRIB_FOLDER) || hasAttribute(ATTRIB_HASSUBFOLDER))
[/pre]
Speeds up things quite noticeably. I don't know if that breaks some other case though.

I don't understand the HASSUBFOLDER check anyway.

Test program (will eat up your inodes or whatever Windoze uses, run only if nobody minds you creating lots of files):
[code]
public class t
{
public static void main(String args[])
throws Exception
{
// Adjust to taste
final int DIRECTORIES = 20;
final int FILES_PER_DIRECTORY = 5000;
String topdir = "openfiletest";

if (new File(topdir).isDirectory()) {
System.out.println("\"" + topdir + "\" already exists");
} else {
System.out.println("creating \"" + topdir + "\"");
new File(topdir).mkdir();
for (int n = 0; n < DIRECTORIES; n++) {
String subdir = topdir + File.separatorChar + n;
new File(subdir).mkdir();
for (int m = 0; m < FILES_PER_DIRECTORY; m++) {
String filename = subdir + File.separatorChar + m;
new FileOutputStream(filename).close();
}
System.out.println("created subdir \"" + subdir + "\"");
}
System.out.println("created \"" + topdir + "\"");
}

JFrame frame = new JFrame();
frame.setVisible(true); // don't ask, I don't know
frame.setVisible(false);
JFileChooser chooser = new JFileChooser(new File("."));
System.out.println("showing dialog");
chooser.showOpenDialog(frame);
File selected = chooser.getSelectedFile();
System.out.println("selected " + selected);
System.exit(0);
}
}
[/code]

mthornton
Offline
Joined: 2003-06-10
Points: 0

Would a ZIP file be an example of an entry which has subfolders but is not itself a folder?

trembovetski
Offline
Joined: 2003-12-31
Points: 0

It might help if you file a bug.

Dmitri

wgradkowski
Offline
Joined: 2005-08-14
Points: 0

Hi,

> It might help if you file a bug.
>

I have. The e-mail from Sun: "We currently have a three week average response time". I'll wait and see ;)

Cheers.

/w.

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Cool, thanks!

Dmitri