could someone here show me a demo how to write these kind of code that
list files or directories recursively in high efficiency just like
native program's speed?
I too have found File.list is pretty slow, even when Jet compiled.
see
http://mindprod.com/jgloss/jet.html
Here is a method that uses two filters, one for directories and one
for files to find junk to get rid of:
/**
* Delete junk files in given fully qualified directory, and all
subdirs.
* uses current definition of junk. Wipes out files matching
definition of
* junk, not dirs.
*
* @param pDir
* fully qualified directory. Would normally be some
existing
* directory.
* @param pRecursive
* true if should also clean subdirs of this dir.
*/
public static void cleanDir ( File pDir, boolean pRecursive )
{
if ( pDir == null ) return;
// clean out child dirs
if ( pRecursive )
{
// all immediate child subdirs of this dir.
String[] allDirs = pDir.list( mDirFilter );
if ( allDirs != null )
{
for ( int i = 0; i < allDirs.length; i++ )
{
cleanDir( new File( pDir, allDirs[ i ] ), true );
}
}
}
// just junk files in this dir, not dirs themselves.
String[] allFiles = pDir.list( mJunkFilter );
if ( allFiles != null )
{
for ( int i = 0; i < allFiles.length; i++ )
{
deleteFile( new File( pDir, allFiles[ i ] ) );
}
}
}
I don't know WHY File.list is so slow. Before embarking on replacing
it with JNI check out its code to see if it doing anything obviously
stupid or overly generic that you could improve on.
I use 4NT which every once in while builds directory tree and stores
it as a flat file. It can find directories in a fraction of a second.
That approach might be suitable for some problems.
In the Replicator, I build an structure to look up files where
segments used to create names are stored as an array of interned
String constants to represent each name. This conserves RAM.
