JFileChooser performance in huge directory

Customer has problem with opening huge directory over network. Directory conatains more than 1000 files. He can't accept dividing content to more directories. Time for open list of files is approx. 60 sec. If I open this directory from explorer time is 2 seconds. May help me Please ?

I have the same problem (1.4beta2 and beta3) in a directory having 4000 files. 1000 files take only a few second though.
I figured out the problem was because of isDirectory which takes an incredible amount of time.
Sun was notified of this bug but they said it is irreproductible, back in 1997: http://developer.java.sun.com/developer/bugParade/bugs/4071318.html
A hack would be to replace the isDirectory function and say:
boolean isDirectory() {
return file.getName().indexOf('.')<0 && file.isDirectory();
}I didn't do it on jfilechooser (but on a filefilter), still hoping it will resolve by itself in the 1.4 release :)

Similar Messages

Performance concern with directory server implementation

performance concern with directory server implementation
I first posted this at metalink forum, and was suggested to post it here instead.
Hi,
I'd like to get any feedback regarding performance of oracle directory server implementation. Below is what I copy&patested from 9i Net Services Administrator's Guide, I found no 'directory server vendor documentation', so anything regarding this is welcome too.
Performance
Connect identifiers are stored in a directory server for all clients to access.
Depending on the number of clients, there can be a significant load on a directory
server.
During a connect identifier lookup, a name is searched under a specific Oracle
Context. Because of the scope of the lookup, you probably want users to experience
relatively quick performance so that the database connect time is not affected. Users
may begin to notice slow connect times if lookups takes more than one second.
You can resolve performance problems changing the network topology or
implementing replication.
See Also: Directory server vendor documentation for details on
resolving performance issues
Thanks.
Shannon

Shannon,
you can find some tuning advises in the following
a) OiD Capacity Planning Considerations
http://download-west.oracle.com/docs/cd/B10501_01/network.920/a96574/cap_plan.htm#1030019
b) Tuning Considerations
http://download-west.oracle.com/docs/cd/B10501_01/network.920/a96574/tuning.htm#999468
c) oracle net services
http://download-west.oracle.com/docs/cd/B10501_01/network.920/a96579/products.htm#1005697
you should start with a) to get an overview what to be aware of
--Olaf

Looping through HUGE directory - How to do so most efficiently?

Hello,
I have a HUGE directory (200k files or so) - currently I'm using the below method to read the file names and place the results into a map. However, this is on a windows box and to run the class that uses this, I have to increase the memory usage via args to get it to run. Is there a better/more efficient way to interate through a huge directory? So for example, if I want to compare each file name in the directory to another filename in a List, how can I get a glob of files (say 100 or so), check that list, and return to the position I left off at?
    private Map listAllFiles() {
        Map files = new HashMap();
        File dir = new File(DIR_PATH);
        if (dir.exists() && dir.isDirectory()) {
            try {
                dir = dir.getCanonicalFile();
                File[] f = dir.listFiles();
                for (int i = 0; i < f.length; i++) {
                    files.put(f.getName(), f[i].getPath());
} catch (Exception e) {
e.printStackTrace();
return files;

SuperBadLuck wrote:
for each file run a preparedstatementOh dear. Running 200 thousand SQL statements doesn't sound fast, even if you're using PreparedStatements.
I am gathering that this is your situation: You have a directory, and a list of files in a database. You want to delete any file that is in the directory but not in the database. Apparently selecting the whole list of files in the database overruns your heap space, so you want to break it down.
Here's what I'd do:
For a chunk of files length M:
cleanChunk(SortedSet files) {
   String lower = files.first();
   String upper = files.last();
   //execute query SELECT db_files.path FROM db_files WHERE db_files.path BETWEEN lower and upper ORDER BY db_files.path;
   for each row in result set {
     files.remove(row);
   for each path in files{
      delete_file(path);
}That leaves the implementation of how you call cleanChunk up to the caller (whether you use an iterator over the directory and add each file to a set, calling cleanChunk every M files and then clearing the set, or some other method). Then you just need to optimize M.
Edited by: endasil on 31-Mar-2008 3:30 PM

JFileChooser with FileSystemView Selecting directory

Hi,
I am using JFileChooser and with my own implementation of FileSystemView .
It is imposable to select a Directory.
Q1. Do you have any clue about the problem?
Q2. Is there any way I can add action listener to "Open" button.
or listen to the events of "Open" button.
Note:
fileChooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);is set.
Regards,
Byju

In the future, Swing questions should be posted to the Swing forum:
http://forum.java.sun.com/forum.jspa?forumID=57
If you have to select a directory, not an ordinary file, why not do this first?
fileChooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);

CS4 poor dialog window performance with huge screen dual 30 inch

Hi, I am running dual 30 inch monitors each one at 2560x1600 resolution, on windows xp sp3 on an nvidia quadro FX 3700M (dell precision M6400 laptop)
If I use CS4 from the single laptop screen, everything is fine. However, whenever Im on the huge dual screen desktop any dialog box activity has a very poor performance. For example, I select File>New and the dialog window takes some two to three seconds to draw on the screen... it might not seem like a big problem but it is very very annoying since I am used to the snappy response of the user interface from years of PS use. It really affects my workflow since I work with many files at the same time.
Also, the bigger the dialog window the slower it takes to appear. If I select File > Save for Web and Devices, that dialog window will take up to five seconds to appear on the screen.
The problem seems to get worse the longer the OS has been working, ie. if the PC is freshly booted the problem seems a bit lighter. So it might be related to video card memory or something.
Here's what I have tried so far to solve this:
Since what I'm using is a laptop, the driver choices are limited, however I've been able to force install the 181.20 version of the nvidia driver, but it made no difference. All the official driver versions (176 series) from Dell also have the problem.
The problem doesn't seem related to Photoshop's use of the GPU as the problem remains while the GPU acceleration disabled.
This problem is also present in PS CS3 as well as CS2 CS1 and version 7 which are all I am able to test.
I was able to reproduce this problem on a desktop computer with the same setup on an nvidia quadro FX 5500 card. The dialog box window performance is really terrible.
I did not notice this problem in any other application that spans the two screens, even high end 3d ones.
Ok well it seems from my testing that Photoshop is simply bogged down by having such a huge desktop area to work with. It is really disappointing since PS was my only reason to spend so much money on this dual 30 inch screen setup.
Has anyone else noticed this? Are there any other suggestions? Any adobe support on this?
Thank you

I have tried with both open gl enabled and disabled (edit > preferences > performance)
The problem is present even in Photoshop version 7, I think that one didnt even notice the presence of a 3d accelerator chip.
Both video cards tested have 1GB of video ram.
Thanks.

JFilechooser Issues with Current Directory

Hi,
Actually I am getting strange error while using JFileChooser.
I am trying to set current directory in applet as:
private static File visitedDir = null;
JFileChooser fc = fileAccess.newJFileChooser();
fc.setDialogType (JFileChooser.OPEN_DIALOG);
if (visitedDir != null) {
fc.setCurrentDirectory(visitedDir);
File file = fc.getSelectedFile();
visitedDir = file.getParentFile();
And when i open the Dialog Box and browse any directory and then in that directory in textbox if I type any file name to create the file. and then say open.And again if open the dialog box,as visited directory is static field it remains initialized. and dialog box shows me directory name in drop down.But it doesn't show me the full traverse path of directory.It only shows that directory name in dialog box.So I cant traverse to any other directory.
Please help.

It works for me - I'm guessing fileAccess.newFileChooser() already shows the dialog, so you only set the current directory after the user picked a file.
public class TestFileChooser {
    public static void main(String[] args) {
        EventQueue.invokeLater(new Runnable() {
            public void run() {
                JFileChooser chooser = new JFileChooser();
                while(chooser.showOpenDialog(null) ==
                          JFileChooser.APPROVE_OPTION) {
                    File file = chooser.getCurrentDirectory();
                    chooser = new JFileChooser();
                    chooser.setCurrentDirectory(file);
}

JFileChooser for selecting a directory !!

Hi,
here's a question for u. I am using a JFileChooser with an "Open" dialog for
choosing a directory by
JFileChooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY). Now it
works fine, except when i double click on a directory, which sets the
directory name in the "File Name" text box, now if I press "Open", it does
nothing, coz it cannot find that directory in this directory as it is
already in that directory!!
The way to make it work is to clear the "File Name" box and then press
"Open", which is very unprofessional and no dumb user will think of doing
that.
What feel is that the only way to do this is to be actually able to
access/modify the Open dialog box, which as far as I know, there is no way
as it is handled by the JVM itself.
Thanks for ur consideration.
P. Cheema

There are several problems with choosing directories from the JFileChooser, (I won't go into them here). I have written the following class to choose directories. I have only tested this some on windows, but it could be a good starting point for others.
import javax.swing.*;
import java.io.*;
import javax.swing.plaf.*;
import javax.swing.plaf.basic.*;
public class DirectoryChooser extends JFileChooser {
    public DirectoryChooser(File startDir) {
        super(startDir);
        this.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
    public File getSelectedFile() {
        File    file    = super.getSelectedFile();
        if (file == null) {
            return file;
        String dirName = super.getSelectedFile().getAbsolutePath();
        String fileSep = System.getProperty("file.separator", "\\");
        if (dirName.endsWith(fileSep + ".")) {
            dirName = dirName.substring(0, dirName.length() - 2);
            file    = new File(dirName);
        return file;
    public void setCurrentDirectory(File file) {
        // Let the action take place, then override the 'Name' field.
        // This is equivalent to the user typing "." in the name field.
        super.setCurrentDirectory(file);
        FileChooserUI ui = getUI();
        if (ui instanceof BasicFileChooserUI) {
            ((BasicFileChooserUI)ui).setFileName(".");
[\code]

JFileChooser go into specified directory (dialog)

Hi.
When creating a file-chooser like this:
this.demoFileFC = new JFileChooser();
this.demoFileFC.setSelectedFile(someDirectoryFile);someDirectoryFile is a java.io.File that is set to an existing directory. The problem now is that when I create a dialog using the "showOpenDialog(parentFrame)" method that the view shows me view from one level above.
E.g. if the someDirectoryFile would be set to "D:\temp\test", then the dialog would be in the directory "D:\temp". How can I set it up that it actually goes into the D:\temp\test\ directory? Is it only possible by hacking, that is, by adding some bogus stuff to the File
(e.g. File someDirectoryFile = new File("D:\\temp\\test\\bogusString") ?
I also have a second question: if the File object I hand to the filechooser's setSelectedFile() method is actually a file, how can I make the showOpenDialog to actually select (blue background) the selected file (instead of just showing its name in the File name field at the bottom of the dialog) ?
Kind regards!

Thanks, that helped.
Does anybody have an idea about my other question, that a file set by filechooser.setSelectedFile(...) is also selected (marked) automatically in the dialog created by showOpenDialog() ?

JFileChooser and Windows Home-Directory (Eigene Dateien)

Hi,...
How can i get the user-dependent private File-Folder (Eigene Dateien) from
the JFileChooser.
I only get a null when i select this folder.
If i select a folder inside the home-folder, i get the realpath
The second pint is, that it is not possible to access Network-Paths.
Has anybody solutions for that Problems.

System.getProperties().getProperty("user.home")

Performance on huge tables

Hi,
I have an application that should contain 100 million records.
Each record has a primary key.
The application fetches a row using the record primary key.
Can anyone tell me what is the problem when using such a big table?
What is the performance of the index on 100 million records?
What is the performance of updates?
Thanks
dyahav

user10952094 wrote:
Can anyone tell me what is the problem when using such a big table?
What is the performance of the index on 100 million records?
What is the performance of updates?It is not about the size of the table.
It is about the size of the I/O.
In other words, how efficient the I/O paths are for getting to the required rows. A small table can cause worse performance problems than a table 10x its size due to the way the smaller table has been defined and is used.
Simple (real world) example:
SQL> select count(*) from daily_xxxxx;
COUNT(*)
2255362806
Elapsed: 00:00:12.03
SQL>Same database, a select against the data dictionary (containing only a couple of rows in comparison):
SQL> select count(*) from all_objects;
COUNT(*)
50908
Elapsed: 00:00:49.17The difference is caused by the amount and nature of I/O that was done - not by the sizes of the tables.
There are however certain features in Oracle that can be used to effectively scale large tables for performance... and make data management significantly easier. The Partitioning Option is an Oracle Enterprise Edition feature that can be considered as an essential, if not a mandatory feature, for effectively dealing and scaling with very large tables (VLT).
However, such a feature aside - the same rules for effective performance for a small table apply to effective performance on large tables. So do not treat a VLT differently. The fundamentals for performance and scalability do not change.

What's the best way to re-read/refresh huge directory of music in iTunes?

I have several hundred GB of 320kbps rips from my CD collection in a few of areas of my computer, spanning a few drives. I want to put them all together and then have iTunes - reindex the new centralized directory (new name). What's the quickest way to get iTunes to reindex & check allthe files/names/directories/etc.?
Thanks

Also, is there any 3rd party tool, or an easy way to set a ID3 tag on all MP3's in a certain directory? I'd have been tagging the "Comment" field" of all my ripped CD's that say "Baseline CD Collection - Imported xx/xx/xx". Since I have these three disparate directories, I want to tag them all differently, so it would be good if I could do this via the Finder instead trying to figure out which files are which once imported within iTunes.

Performance: reading huge amount of master data in end routine

In our 7.0 system, each day a full load runs from DSO X to DSO Y in which from six characteristics from DSO X master data is read to about 15 fields in DSO Y contains about 2mln. records, which are all transferred each day. The master data tables all contain between 2mln. and 4mln. records. Before this load starts, DSO Y is emptied. DSO Y is write optimized.
At first, we designed this with the standard "master data reads", but this resulted in load times of 4 hours, because all master data is read with single lookups. We redesigned and fill all master data attributes in the end routine, after fillilng internal tables with the master data values corresponding to the data package:
*   Read 0UCPREMISE into temp table
    SELECT ucpremise ucpremisty ucdele_ind
      FROM /BI0/PUCPREMISE
      INTO CORRESPONDING FIELDS OF TABLE lt_0ucpremise
      FOR ALL ENTRIES IN RESULT_PACKAGE
      WHERE ucpremise EQ RESULT_PACKAGE-ucpremise.
And when we loop over the data package, we write someting like:
    LOOP AT RESULT_PACKAGE ASSIGNING <fs_rp>.
      READ TABLE lt_0ucpremise INTO ls_0ucpremise
        WITH KEY ucpremise = <fs_rp>-ucpremise
        BINARY SEARCH.
      IF sy-subrc EQ 0.
        <fs_rp>-ucpremisty = ls_0ucpremise-ucpremisty.
        <fs_rp>-ucdele_ind = ls_0ucpremise-ucdele_ind.
      ENDIF.
*all other MD reads
ENDLOOP.
So the above statement is repeated for all master data we need to read from. Now this method is quite faster (1,5 hr). But we want to make it faster. We noticed that reading in the master data in the internal tables still takes a long time, and this has to be repeated for each data package. We want to change this. We have now tried a similar method, but now load all master data in internal tables, without filtering on the data package, and we do this only once.
*   Read 0UCPREMISE into temp table
    SELECT ucpremise ucpremisty ucdele_ind
      FROM /BI0/PUCPREMISE
      INTO CORRESPONDING FIELDS OF TABLE lt_0ucpremise.
So when the first data package starts, it fills all master data values, which 95% of them we would need anyway. To accomplish that the following data packages can use the same table and don't need to fill them again, we placed the definition of the internal tables in the global part of the end routine. In the global we also write:
DATA: lv_data_loaded TYPE C LENGTH 1.
And in the method we write:
IF lv_data_loaded IS INITIAL.
lv_0bpartner_loaded = 'X'.
* load all internal tables
lv_data_loaded = 'Y'.
WHILE lv_0bpartner_loaded NE 'Y'.
Call FUNCTION 'ENQUEUE_SLEEP'
EXPORTING
     seconds = 1.
ENDWHILE.
LOOP AT RESULT_PACKAGE
* assign all data
ENDLOOP.
This makes sure that another data package that already started, "sleeps" until the first data package is done with filling the internal tables.
Well this all seems to work: it takes now 10 minutes to load everything to DSO Y. But I'm wondering if I'm missing anything. The system seems to work fine loading all these records in internal tables. But any improvements or critic remarks are very welcome.

This is a great question, and you've clearly done a good job of investigating this, but there are some additional things you should look at and perhaps a few things you have missed.
Zephania Wilder wrote:
At first, we designed this with the standard "master data reads", but this resulted in load times of 4 hours, because all master data is read with single lookups.
This is not accurate. After SP14, BW does a prefetch and buffers the master data values used in the lookup. Note [1092539|https://service.sap.com/sap/support/notes/1092539] discusses this in detail. The important thing, and most likely the reason you are probably seeing individual master data lookups on the DB, is that you must manually maintain the MD_LOOKUP_MAX_BUFFER_SIZE parameter to be larger than the number of lines of master data (from all characteristics used in lookups) that will be read. If you are seeing one select statement per line, then something is going wrong.
You might want to go back and test with master data lookups using this setting and see how fast it goes. If memory serves, the BW master data lookup uses an approach very similar to your second example (1,5 hrs), though I think that it first loops through the source package and extracts the lists of required master data keys, which is probably faster than your statement "FOR ALL ENTRIES IN RESULT_PACKAGE" if RESULT_PACKAGE contains very many duplicate keys.
I'm guessing you'll get down to at least the 1,5 hrs that you saw in your second example, but it is possible that it will get down quite a bit further.
Zephania Wilder wrote:
This makes sure that another data package that already started, "sleeps" until the first data package is done with filling the internal tables.
This sleeping approach is not necessary as only one data package will be running at a time in any given process. I believe that the "global" internal table is not be shared between parallel processes, so if your DTP is running with three parallel processes, then this table will just get filled three times. Within a process, all data packages are processed serially, so all you need to do is check whether or not it has already been filled. Or are you are doing something additional to export the filled lookup table into a shared memory location?
Actually, you have your global data defined with the statement "DATA: lv_data_loaded TYPE C LENGTH 1.". I'm not completely sure, but I don't think that this data will persist from one data package to the next. Data defined in the global section using "DATA" is global to the package start, end, and field routines, but I believe it is discarded between packages. I think you need to use "CLASS-DATA: lv_data_loaded TYPE C LENGTH 1." to get the variables to persist between packages. Have you checked in the debugger that you are really only filling the table once per request and not once per package in your current setup? << This is incorrect - see next posting for correction.
Otherwise the third approach is fine as long as you are comfortable managing your process memory allocations and you know the maximum size that your master data tables can have. On the other hand, if your master data tables grow regularly, then you are eventually going to run out of memory and start seeing dumps.
Hopefully that helps out a little bit. This was a great question. If I'm off-base with my assumptions above and you can provide more information, I would be really interested in looking at it further.
Edited by: Ethan Jewett on Feb 13, 2011 1:47 PM

Resume building library from huge directory

I have been trying to build my iTunes library but it is taking a very long time due to the fact it needs to convert about half the songs (4000). I have gotten up to about 2000 of 6000 songs so far but would like to use my iPod and come back to resume building the library later. Every time I try to do this it starts over and reconverts the same files making duplicates. How do I resume instead of adding the original folder to the library again?
What am I doing wrong? How can I build my library, use my iPod and not make thousands of duplicates?
Thanks,
MB

This is not a java problem.
It is a VM problem.
So for the VM (vendor and version) that you are using it requires certain things.
It might be that the VM doesn't load 32 at all. Or that you have to do something different when you compile it.
A forum that is specific to your VM might be more productive (this site tends to be strongly solaris/linux/windows.)

Problem using JFileChooser to select a destination directory

If you set JFileChooser to DIRECTORIES_ONLY, a user has to single click on the desired directory and click on the approveButton. This works just fine - you get the user's desired directory using getSelectedFile().
e.g. /home/joeuser/docs
But if the user double-clicks on their desired directory (a common user practice), the directory is opened AND the directory name is stuck in the File Name: field. If they now click on the approveButton, the returned selected directory is the user's desired directory PLUS the name of the directory again. Not what the user intended.
e.g. /home/joeuser/docs/docs
Now, when you keep the File Name: field from being filled in when the user double-clicks on a directory, you have encounter another problem. The approveButton will not activate unless there is something in the File Name: field!
Does anybody have a solution for the approveButton working with an empty File Name: field?
Thanks,
Scott

I had the same problem. Gave up with JFileChooser and made a directory chooser that only display the diectory structure in a JTree and no file stuff at all.
Source: http://www.msticky.freeserve.co.uk/JDialog_directoryChooser.java
to use it; String selectedDirPath=JDialog_directoryChooser.choose(stringTitle, stringInitialSelectedPath)
returns the selected directory path or null if none selected.
To make it work alone you'll need to remove my RRException class. If you want to see it in use first download noname.jar from http://www.msticky.freeserve.co.uk
ps. my site needs testing
thanks, sticky

Using JFileChooser to select directory only

Hi. I am using JFileChooser to let the user to select the directory to save some files into the user-selected directory. I set the JFileChooser to show only directory and not files. Below show part of my code:
private JFileChooser chooser = new JFileChooser();
chooser.setFileHidingEnabled(true);
chooser.setMultiSelectionEnabled(false);
chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
chooser.setDialogType(JFileChooser.OPEN_DIALOG);
int state = chooser.showDialog(frame, "Select Directory");
if (state == JFileChooser.APPROVE_OPTION )
file = chooser.getCurrentDirectory();
However, the File reference that i get is not the user-selected directory. Please help.
Thank you.

Hi,
i found that if user writes in the text field of save dialog name of the file(but application needs directory), getCurrentDirectory() returns correct directory. but if user chooses directory, getCurrentDirectory() returns parent directory but getSelectedFile() returns correct one, so i suggest something like this(it's nasty but it works [i hope;])
JFileChooser dirChooser = new JFileChooser("");
dirChooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
if (dirChooser.showSaveDialog(this) == JFileChooser.APPROVE_OPTION)
java.io.File curDir = dirChooser.getSelectedFile().isDirectory()?dirChooser.getSelectedFile():dirChooser.getCurrentDirectory();

JFileChooser performance in huge directory

Similar Messages

Maybe you are looking for