java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)


The JFileChooser for 1.4, while it has improvements over 1.3, has
one glaring problem: it continuously polls the directory contents,
making it impossibly slow, even over a network as fast as 10Mbps.

For example: mount a remote drive, and navigate there with 1.3's
JFileChooser.  Scroll up and down in the list (don't even need to
select different files, just scroll the view).  No network
activity.  Try the same with 1.4, and it's extremely sluggish --
and your hub's activity light goes solid.  Yow!
(Review ID: 128097) 
======================================================================




java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)


In any Java app that uses JFileChooser, try browsing a
network-mounted disk.  You may notice that:

- it's sluggish (unless you're on a super-fast network,
I suspect)

- if you even scroll the view by 1 pixel, your hub activity
light blinks

It looks like the TableModel getValue() (or something like
that) calls File.list(), which works ok for local drives,
but causes lots of network traffic for remote drives.  On
our 10mbps network, it's too slow for everyday use.

It does seem a little better than 1.4b1, but much worse
than 1.3/1.3.1.

(I submitted this for 1.4b1, but I can't find it in the database
now, and I want to make sure it's still on the radar.)
(Review ID: 131260)
======================================================================




FULL PRODUCT VERSION :
Tested under 1.3.0, JRE 1.3.1_* and JRE 1.4.0

FULL OPERATING SYSTEM VERSION :
Windows 2000 [Version 5.00.2195]

ADDITIONAL OPERATING SYSTEMS :
Win 98

EXTRA RELEVANT SYSTEM CONFIGURATION :
There are Directorys with 2000 up to 4000 HTML files
(Most about 1 or 2 Kb) on a Linux server with
Samba. The clients are connected via 100 MBit

A DESCRIPTION OF THE PROBLEM :
When I try to load a large directory from a Samba
Server via Linux it take about 5 to 10 seconds (ie: in
a JFileChooser). Under Windows it take about 30 MINUTES
to show the contents of the same directory. The Windows
Explorer shows up the content in 10 or 20 Seconds. A
simple testprogram (see sourcecode) shows what could be
the problem:

Linux: (JDK1.3.1)

needed: 436ms for String list
needed: 128ms for File list
needed: 170ms For Dir-Scanning

Windows 2k: (JDK1.3.1)
needed: 1402ms for String list
needed: 721ms for File list
needed: 14531ms For Dir-Scanning

It's the same directory on the same server! (3128 Files)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Open a JFileChooser
2. Try opening a large remote Directory
3. Try it again under Linux

EXPECTED VERSUS ACTUAL BEHAVIOR :
I think every call to File.isDirectory, etc. is doing a
explicit call to the server. These things should be
cached
and eventually updated through a timer task

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.*;
  import java.util.Date;

public class PerformanzTest {

  public PerformanzTest () {
  }

  /** Start the programm with a directory as parameter */
  public static void main (String[] args) {
    File f = new File(args[0]);
    restartT();
    String[] tmp = f.list ();
    printT("for String list");
    restartT();
    File[] tmp2 = f.listFiles ();
    printT("for File list");
    restartT();
    for (int i = 0; i < tmp2.length; i++){
      tmp2[i].isDirectory();
    }
    printT("For Dir-Scanning");
  }

  static long time;
  private static final void restartT(){
    time = new Date().getTime ();
  }

  private static final void printT(String info){
    System.out.println("needed: "+(new Date().getTime()-time)+"ms "+info);
  }
}

---------- END SOURCE ----------
(Review ID: 147119)
======================================================================
Posted Date : 2005-09-20 17:40:49.0

(None -- stick with 1.3.1)
======================================================================

This is probably fixed in 1.4.2 as a result of fix for bug 4712307.
  xxxxx@xxxxx   2003-02-27

Problem remains for Windows L&F in 1.4.2. Still about 10x slower
for remote file systems.
  xxxxx@xxxxx   2003-07-07

Will investigate how caching can be achieved for remote folders without
further slowing down local attribute access.
  xxxxx@xxxxx   2005-1-07 21:08:58 GMT
The slowness happens in the File.length() call, which is used for the Size columns. This will be fixed by using native ShellFolder2 API to get the details information as a fix for CR 4968362.
Posted Date : 2005-09-20 17:44:06.0

Scrolling is now considerably faster in Mustang, especially after the fix for 4968362. Closing this as "not reproducible".
Posted Date : 2005-11-08 00:44:18.0

I'm mounting network drives on a Gigabit network and are 
getting the same results. Sluggish browsing of remote 
directories. Thus canning the idea "it's sluggish (unless 
you're on a super-fast network,
I suspect)"

My lab is now on a 100 megabit network and 1000 MHz
workstations, so I figured I'd install 1.4 on one
workstation to see how it goes (and decide if I want
to upgrade the rest yet).

The one comment I got: "It works fine, but it's slow."

Seems to me all those impressive graphs showing how I/O
and reflection and Java2D are 2000% faster don't mean much
if it takes me 15 or 20 seconds to select a file.

No matter how efficient a Swing application is, this bug 
will always make it look bad. Even if I wanted to use 
java.awt.FileDialog instead as a workaround, I couldn't do 
it for multiple file selections.

I have several programs that use JFileChooser and they work 
apparently well in the versions 1_3_2_02 and 1_4_0. 
However, in the version 1_4, the worn-out times for 
JFileChooser is much larger than in the previous version. 
If the amount of selected files goes very big, more than 
2000, I don't obtain answer. In one of the tests I selected 
7500 files and 10 hours later I aborted the execution 
because JFileChooser had not still closed the window OPEN. 
  
Seemingly the problem is in RunTime. I executed in the two 
versions programs compiled in the two versions. The problem 
shows when I use RunTime 1_4 independently of the version 
where the program was compiled.  

OS: Windows ME and Windows 2000, without network.

On Win98 and WinME, browsing the Network Neighborhood with
JFileChooser using JRE1.4.x brings the system to its knees.
 You can watch the System and GDI resources in the Resource
Meter go to zero.  Win2k exhibits very slow response. 

With the AWT FileDialog this does not happen.

and while it is really slow, the JFileChooser dialog does not 
repaint itself!!  Can handle it being slow (ok, not really), but 
why doesn't the frame repaint in an another thread while 
getting the file list?

I've had to go back to using the awt file dialog.  
Some remote directories my users have to look at
have over 1000 files.   The vanilla 1.4 JFileChooser takes
over a minute to display these directories.

Sun comment: We are about to close this as a duplicate of 
bug 4712307, which was fixed in 1.4.2 beta. Because there 
are so many votes for this I just want to give everybody a 
chance to speak up if you think this is an incorrect 
assessment.

Cheers,

Leif Samuelsson
Java Swing Team
Sun Microsystems, Inc.

The bug seems to occur even in 1.4.2 (1.4.2_b28), at least
on windows 2000

Browsing a remote drive with many files (~27000 objects)
gives me the following results :

notepad (system widget) opens in about 7s.
JFileChooser (Metal or Motif L&F) : about 7-8s
JFileChooser (Windows L&F) : about 100s

This is for the first execution only. Subsequent executions
are ways faster...

Could this be due to the loading of file icons ?

I dug up the old code, and the odd thing is that it is fast
even when compiled under new java so my theory is out the
window. I can't see any difference in the implementations
between the code I have that has slow file dialogs and the
code that has fast dialogs.... Sorry for the noise on this
bug, but I just found a work around that seems to work for
my code. In the program that was slow  I lazy initialized
created the JFileChooser like this:

    private JFileChooser saveDlg;

... then later ...

        if (saveDlg == null) {
            saveDlg = new JFileChooser();
        }

The result was the file dialog that takes seconds to chage
directories....

By simply amending the declaration to include instantiation
like this:

    private JFileChooser saveDlg = new JFileChooser();

Two things changed... First, my startup time for the program
went from 1 sec to 10-15 sec. Second. The save dialog was
able to change directories without thrashing the proccessor.
This is really wierd since it seems to mean that the
JFileChooser constructor returns different objects depending
on whether it is called at the time the main class is
instantiated, or later.

I would like to amend my last comment to note that  the
difference initally noted was not the look and feel, but
when it was compiled. (The old program uses the same L&F as
the newer one of my own that does exhibit the problem).

basically ignore the clause above that says:

but not my personal code using the metal default L&F. 

I am definately seeing this in
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

I see it when using Netbeans, Posiedon for UML, and CGoban2,
but not my personal code using the metal default L&F. I have
no network drives. My system is Windows XP [Version
5.1.2600]. The machine is Athlon 2500 (Barton) on an Asus
A7N8 Deluxe MB with Geforce 4 4200ti... Windows task manager
shows my machine goes to 100% CPU for about 10 sec while
initializing the dialog, and then when I try to change
folders it takes about 5 seconds. During the processor spike
I usually get one or two updates to Task Manager, and the
memory usage actually DROPS by a megabyte during the spike
and returns  to it's original level. I'd say something big
is geting GC'd and recreated. (system has 640MB, usually
with at least 256MB to spare). Interestingly a program I
compiled a long time ago (year?) under linux doesn't seem to
display this problem even when running on my windows box.

Maybe something is over optimized.... and dropping a reference?

I also should have added that it doesn't seem to matter how
many files are in the directory. My opservations are of
directories < 50 files (some with 2)

This has nothing to do with remote folders.  Local folders can also be brutally slow.

Simply constructing a JFileChooser can take a few seconds, even if you don't show it.  I have tried to work around the problem by caching my JFileChoosers so the second time the chooser is used it pops up right away.

It appears that the File methods in general are very slow and need to be optimized.  Just getting a list of files with the File class needs to be sped up.

As of Mustang build 58 (the beta build), the details columns are fetched from the native layer on Windows (rfe 4968362). It will hopefully speed things up considerably. Please give it a try and report your findings here. Its available at:
    http://mustang.dev.java.net

I thought I would point out that this issue is still present in Java 1.5.0_06 and that the directory can contain less than ten entries yet the JFileChooser will still take several seconds to construct or change directories.  The issues does NOT happen on all machines, but recently we have seen this on a fresh install on a brand new machine running Win XP SP2.  The application is completely crippled of course.  No wonder our customers are streaming at us if this is what they experience.

Still unacceptably slow in Mustang b68.
sun.awt.shell.Win32ShellFolder2.hasAttribute(int) is horribly slow.  Even with only a few files in the folder this dominates the construction of a JFileChooser by a huge degree.  Construct a UI that also constructs a handful of JFileChooser I found that the hasAttribute method accounted for more than 55% of the processing time -- more than 2 seconds were spent in that method such that user response time of my dialog was unacceptable.  Why is this so much slower than a native dialog?

"Scrolling is now considerably faster in Mustang"
Who cares about scrolling when constructing the JFileChooser and NEVER displaying it is the most expensive operation in my entire program?  This bug should never have been closed since JFileChooser continues to have brutal performance issues.

If you have problems with JFileChooser being very slow, check out bug #6372808 (#5050516 and #5033747 might also be of interest).

In particular, the comment from "gus_olin" which points out that where the JFileChooser is created (in the main class, or later) points to him having the "zipfolder problem" - and the "where it is created" issue is not about where, but in which Thread (The creating thread will always have slow performance (too bad if it is the AWT's EDT, then!), while all others will have fast. Just make a JFileChooser in a new to-be-discarded thread, and you're fine (except from 100% CPU usage for a while!). Or move any zip files away from the Desktop, or do both to be customer-safe.. Or better yet; get Sun to remove the reliance on Win XP's obviously broken zipfolder stuff).

I had this problems until this morning, when I checked the bug Id 6317789 : In my case, the problem was that I had a shortcut on my desktop that pointed to a remote folder, on a machine that was down (on Windows 2000 SP4).
I suppose that the JFC slowness resulted in too long try to resolve the shortcut (but, when my computer was disconnected from the network, there was no problem !). 
=> try to reduce some time out ?
=> or resolve shortcuts only if the user try to use them ?

Please fix the JFC problems, it has a very high negative impact on our end user customers...
Thanks