-
Bug
-
Resolution: Cannot Reproduce
-
P3
-
1.4.0, 1.4.1, 1.4.2_03
-
x86
-
windows_2000, windows_xp
Name: bsC130419 Date: 07/16/2001
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)
======================================================================
Name: nt126004 Date: 09/04/2001
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)
======================================================================
Name: rmT116609 Date: 05/30/2002
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)
======================================================================
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)
======================================================================
Name: nt126004 Date: 09/04/2001
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)
======================================================================
Name: rmT116609 Date: 05/30/2002
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)
======================================================================
- duplicates
-
JDK-5033747 JFileChooser is very slow on Windows XP
-
- Closed
-
- relates to
-
JDK-4712307 JFileChooser is very slow when browsing many files in a directory
-
- Resolved
-
-
JDK-5050516 JFileChooser very slow in XP if directory contains large zip files
-
- Resolved
-
-
JDK-4652211 REGRESSION: JFileChooser is slow in listing directory contents
-
- Closed
-
-
JDK-4968362 Win L&F: JFileChooser should show information like native in detail view
-
- Closed
-