Java получить размер файла эффективно


166

При поиске, я вижу, что использование java.io.File#length()может быть медленным. FileChannelесть size()метод, который также доступен.

Есть ли эффективный способ в Java, чтобы получить размер файла?


7
Можете ли вы предоставить ссылки о том, что File.length () "может быть медленным"?
Мэтт Б

1
извините, вот ссылка javaperformancetuning.com/tips/rawtips.shtml для поиска «Информация о файле, такая как File.length (), требует системного вызова и может быть медленной». это действительно запутанное утверждение, кажется, почти предполагалось, что это будет системный вызов.
joshjdevl

25
Получение длины файла потребует системного вызова независимо от того, как вы это делаете. Это может быть медленно, если это по сети или другой очень медленной файловой системе. Нет более быстрого способа получить его, чем File.length (), и определение «slow» здесь просто означает, что не вызывайте его без необходимости.
jsight

Я думаю, что это то, что GHad пытался проверить ниже. Мои результаты (на Ubuntu 8.04): только один URL доступа самый быстрый. 5 запусков, 50 итераций КАНАЛ еще быстрее сбивает с толку? :) для моих целей я просто сделаю один доступ. хотя это странно? что мы получили разные результаты
joshjdevl

1
Эта операция может быть очень медленной, если информация находится на диске, а не в кеше. (например, в 1000 раз медленнее), однако, вы мало что можете сделать с этим, кроме обеспечения того, что необходимая информация всегда находится в кеше (например, предварительная загрузка и наличие достаточного объема памяти, чтобы она оставалась в памяти)
Питер Лоури,

Ответы:


102

Ну, я попытался измерить это с помощью кода ниже:

Для запусков = 1 и итераций = 1 метод URL быстрее всего следует за каналом. Я запускаю это с некоторой свежей паузой около 10 раз. Таким образом, для однократного доступа использование URL-адреса является самым быстрым способом, о котором я могу думать:

LENGTH sum: 10626, per Iteration: 10626.0

CHANNEL sum: 5535, per Iteration: 5535.0

URL sum: 660, per Iteration: 660.0

Для прогонов = 5 и итераций = 50 картина рисуется иначе.

LENGTH sum: 39496, per Iteration: 157.984

CHANNEL sum: 74261, per Iteration: 297.044

URL sum: 95534, per Iteration: 382.136

Файл должен кэшировать вызовы файловой системы, в то время как каналы и URL имеют некоторые накладные расходы.

Код:

import java.io.*;
import java.net.*;
import java.util.*;

public enum FileSizeBench {

    LENGTH {
        @Override
        public long getResult() throws Exception {
            File me = new File(FileSizeBench.class.getResource(
                    "FileSizeBench.class").getFile());
            return me.length();
        }
    },
    CHANNEL {
        @Override
        public long getResult() throws Exception {
            FileInputStream fis = null;
            try {
                File me = new File(FileSizeBench.class.getResource(
                        "FileSizeBench.class").getFile());
                fis = new FileInputStream(me);
                return fis.getChannel().size();
            } finally {
                fis.close();
            }
        }
    },
    URL {
        @Override
        public long getResult() throws Exception {
            InputStream stream = null;
            try {
                URL url = FileSizeBench.class
                        .getResource("FileSizeBench.class");
                stream = url.openStream();
                return stream.available();
            } finally {
                stream.close();
            }
        }
    };

    public abstract long getResult() throws Exception;

    public static void main(String[] args) throws Exception {
        int runs = 5;
        int iterations = 50;

        EnumMap<FileSizeBench, Long> durations = new EnumMap<FileSizeBench, Long>(FileSizeBench.class);

        for (int i = 0; i < runs; i++) {
            for (FileSizeBench test : values()) {
                if (!durations.containsKey(test)) {
                    durations.put(test, 0l);
                }
                long duration = testNow(test, iterations);
                durations.put(test, durations.get(test) + duration);
                // System.out.println(test + " took: " + duration + ", per iteration: " + ((double)duration / (double)iterations));
            }
        }

        for (Map.Entry<FileSizeBench, Long> entry : durations.entrySet()) {
            System.out.println();
            System.out.println(entry.getKey() + " sum: " + entry.getValue() + ", per Iteration: " + ((double)entry.getValue() / (double)(runs * iterations)));
        }

    }

    private static long testNow(FileSizeBench test, int iterations)
            throws Exception {
        long result = -1;
        long before = System.nanoTime();
        for (int i = 0; i < iterations; i++) {
            if (result == -1) {
                result = test.getResult();
                //System.out.println(result);
            } else if ((result = test.getResult()) != result) {
                 throw new Exception("variance detected!");
             }
        }
        return (System.nanoTime() - before) / 1000;
    }

}

1
Похоже, что URL-путь лучше всего подходит для однократного доступа, будь то XP или Linux. Greetz GHad
GHad

73
stream.available()не возвращает длину файла. Возвращает количество байтов, доступных для чтения, без блокировки других потоков. Это не обязательно то же количество байтов, что и длина файла. Чтобы получить реальную длину из потока, вам действительно нужно прочитать ее (и посчитать считанные байты).
BalusC

11
Этот критерий является или, скорее, его интерпретация неверна. При малом количестве итераций более поздние тесты используют преимущества кэширования файлов операционной системы. В тесте более высоких итераций ранжирование корректно, но не потому, что File.length () что-то кеширует, а просто потому, что другие 2 опции основаны на том же методе, но выполняют дополнительную работу, которая замедляет их.
x4u

2
@Paolo, кэширование и оптимизация доступа к файловой системе - одна из основных обязанностей ОС. faqs.org/docs/linux_admin/buffer-cache.html Для получения хороших результатов тестирования необходимо очищать кэш перед каждым запуском.
z0r

3
Помимо того, что сказано в javadoc для InputStream.available (), тот факт, что метод available () возвращает int, должен быть красным флажком для подхода URL. Попробуйте это с файлом 3 ГБ, и будет очевидно, что это недопустимый способ определения длины файла.
Скрабби

32

Тест, данный GHad, измеряет множество других вещей (таких как отражение, создание объектов и т. Д.) Помимо определения длины. Если мы попытаемся избавиться от этих вещей, то за один звонок я получу следующее время в микросекундах:

   сумма файла ___ 19.0, за одну итерацию ___ 19.0
    raf sum ___ 16.0, за одну итерацию ___ 16.0
сумма канала __273.0 за одну итерацию __273.0

За 100 прогонов и 10000 итераций я получаю:

   сумма файла __1767629.0, за итерацию __1.7676290000000001
    raf sum ___ 881284.0 за одну итерацию__0.8812840000000001
сумма канала ___ 414286.0, за итерацию__0.414286

Я выполнил следующий модифицированный код, указав в качестве аргумента имя файла размером 100 МБ.

import java.io.*;
import java.nio.channels.*;
import java.net.*;
import java.util.*;

public class FileSizeBench {

  private static File file;
  private static FileChannel channel;
  private static RandomAccessFile raf;

  public static void main(String[] args) throws Exception {
    int runs = 1;
    int iterations = 1;

    file = new File(args[0]);
    channel = new FileInputStream(args[0]).getChannel();
    raf = new RandomAccessFile(args[0], "r");

    HashMap<String, Double> times = new HashMap<String, Double>();
    times.put("file", 0.0);
    times.put("channel", 0.0);
    times.put("raf", 0.0);

    long start;
    for (int i = 0; i < runs; ++i) {
      long l = file.length();

      start = System.nanoTime();
      for (int j = 0; j < iterations; ++j)
        if (l != file.length()) throw new Exception();
      times.put("file", times.get("file") + System.nanoTime() - start);

      start = System.nanoTime();
      for (int j = 0; j < iterations; ++j)
        if (l != channel.size()) throw new Exception();
      times.put("channel", times.get("channel") + System.nanoTime() - start);

      start = System.nanoTime();
      for (int j = 0; j < iterations; ++j)
        if (l != raf.length()) throw new Exception();
      times.put("raf", times.get("raf") + System.nanoTime() - start);
    }
    for (Map.Entry<String, Double> entry : times.entrySet()) {
        System.out.println(
            entry.getKey() + " sum: " + 1e-3 * entry.getValue() +
            ", per Iteration: " + (1e-3 * entry.getValue() / runs / iterations));
    }
  }
}

3
на самом деле, хотя вы и правы, говоря, что он измеряет другие аспекты, я должен быть более ясным в своем вопросе. Я ищу, чтобы получить размер файла нескольких файлов, и я хочу самый быстрый способ. так что мне действительно нужно принимать во внимание создание объектов и накладные расходы, поскольку это реальный сценарий
joshjdevl

3
Около 90% времени тратится на эту вещь getResource. Я сомневаюсь, что вам нужно использовать отражение, чтобы получить имя файла, который содержит некоторый байт-код Java.

20

Все контрольные примеры в этом посте имеют недостатки, так как имеют доступ к одному и тому же файлу для каждого протестированного метода. Таким образом, кеширование диска дает преимущества при тестах 2 и 3. Чтобы доказать свою точку зрения, я взял контрольный пример, предоставленный GHAD, и изменил порядок перечисления. Ниже приведены результаты.

Глядя на результат, я думаю, File.length () действительно победитель.

Порядок проверки - это порядок вывода. Вы даже можете видеть, что время, затрачиваемое на моем компьютере, варьируется между выполнениями, но File.Length (), когда не первый, и получение первого доступа к диску выиграно.

---
LENGTH sum: 1163351, per Iteration: 4653.404
CHANNEL sum: 1094598, per Iteration: 4378.392
URL sum: 739691, per Iteration: 2958.764

---
CHANNEL sum: 845804, per Iteration: 3383.216
URL sum: 531334, per Iteration: 2125.336
LENGTH sum: 318413, per Iteration: 1273.652

--- 
URL sum: 137368, per Iteration: 549.472
LENGTH sum: 18677, per Iteration: 74.708
CHANNEL sum: 142125, per Iteration: 568.5

9

Когда я изменяю ваш код, чтобы использовать файл, доступ к которому осуществляется по абсолютному пути, а не по ресурсу, я получаю другой результат (для 1 запуска, 1 итерации и файла размером 100 000 байт - время для 10-байтового файла совпадает с 100 000 байтов )

ДЛИНА сумма: 33, за итерацию: 33,0

Сумма КАНАЛА: 3626, за Итерацию: 3626.0

Сумма URL: 294, за итерацию: 294,0


9

В ответ на тест rgrig, время, необходимое для открытия / закрытия экземпляров FileChannel & RandomAccessFile, также необходимо учитывать, так как эти классы откроют поток для чтения файла.

После изменения эталонного теста я получил эти результаты за 1 итерацию для файла размером 85 МБ:

file totalTime: 48000 (48 us)
raf totalTime: 261000 (261 us)
channel totalTime: 7020000 (7 ms)

Для 10000 итераций в одном файле:

file totalTime: 80074000 (80 ms)
raf totalTime: 295417000 (295 ms)
channel totalTime: 368239000 (368 ms)

Если все, что вам нужно, это размер файла, то file.length () - самый быстрый способ сделать это. Если вы планируете использовать файл для других целей, таких как чтение / запись, тогда лучше использовать RAF. Только не забудьте закрыть файл подключения :-)

import java.io.File;
import java.io.FileInputStream;
import java.io.RandomAccessFile;
import java.nio.channels.FileChannel;
import java.util.HashMap;
import java.util.Map;

public class FileSizeBench
{    
    public static void main(String[] args) throws Exception
    {
        int iterations = 1;
        String fileEntry = args[0];

        Map<String, Long> times = new HashMap<String, Long>();
        times.put("file", 0L);
        times.put("channel", 0L);
        times.put("raf", 0L);

        long fileSize;
        long start;
        long end;
        File f1;
        FileChannel channel;
        RandomAccessFile raf;

        for (int i = 0; i < iterations; i++)
        {
            // file.length()
            start = System.nanoTime();
            f1 = new File(fileEntry);
            fileSize = f1.length();
            end = System.nanoTime();
            times.put("file", times.get("file") + end - start);

            // channel.size()
            start = System.nanoTime();
            channel = new FileInputStream(fileEntry).getChannel();
            fileSize = channel.size();
            channel.close();
            end = System.nanoTime();
            times.put("channel", times.get("channel") + end - start);

            // raf.length()
            start = System.nanoTime();
            raf = new RandomAccessFile(fileEntry, "r");
            fileSize = raf.length();
            raf.close();
            end = System.nanoTime();
            times.put("raf", times.get("raf") + end - start);
        }

        for (Map.Entry<String, Long> entry : times.entrySet()) {
            System.out.println(entry.getKey() + " totalTime: " + entry.getValue() + " (" + getTime(entry.getValue()) + ")");
        }
    }

    public static String getTime(Long timeTaken)
    {
        if (timeTaken < 1000) {
            return timeTaken + " ns";
        } else if (timeTaken < (1000*1000)) {
            return timeTaken/1000 + " us"; 
        } else {
            return timeTaken/(1000*1000) + " ms";
        } 
    }
}

8

Я столкнулся с этой же проблемой. Мне нужно было получить размер файла и дату изменения в 90000 файлов на сетевом ресурсе. Используя Java и будучи максимально минималистичным, это займет очень много времени. (Мне нужно было получить URL из файла, а также путь к объекту. Так что он несколько варьировался, но больше часа.) Затем я использовал собственный исполняемый файл Win32 и выполнил ту же задачу, просто выгрузив файл путь, измененный и размер к консоли и выполненный из Java. Скорость была потрясающая. Собственный процесс и обработка строк для чтения данных могут обрабатывать более 1000 элементов в секунду.

Поэтому, несмотря на то, что люди оценили приведенный выше комментарий, это правильное решение, и оно действительно решило мою проблему. В моем случае я знал, какие папки мне нужны заранее, и мог передать это в командной строке своему приложению win32. Я шел от часов, чтобы обработать каталог до минут.

Проблема также, кажется, была специфичной для Windows. OS X не имела такой же проблемы и могла получить доступ к информации о сетевых файлах так же быстро, как и ОС.

Обработка файлов Java в Windows ужасна. Локальный доступ к файлам для файлов все же хорошо. Это были просто сетевые ресурсы, которые вызвали ужасную производительность. Windows может получить информацию об общем сетевом ресурсе и вычислить общий размер за минуту.

--Бен


3

Если вы хотите размер файла нескольких файлов в каталоге, используйте Files.walkFileTree. Вы можете получить размер из того, BasicFileAttributesчто вы получите.

Это намного быстрее, чем вызов .length()результата File.listFiles()или использование Files.size()результата Files.newDirectoryStream(). В моих тестовых случаях это было примерно в 100 раз быстрее.


К вашему сведению, Files.walkFileTreeдоступно на Android 26+.
Джошуа Пинтер

2

На самом деле, я думаю, что «лс» может быть быстрее. В Java определенно есть некоторые проблемы, связанные с получением информации о файле. К сожалению, нет эквивалентного безопасного метода рекурсивного ls для Windows. (DIR / S cmd.exe может запутаться и генерировать ошибки в бесконечных циклах)

В XP при доступе к серверу в локальной сети у меня уходит 5 секунд в Windows, чтобы получить количество файлов в папке (33 000) и общий размер.

Когда я повторяю это в Java, это занимает у меня более 5 минут. Я начал измерять время, необходимое для выполнения функций file.length (), file.lastModified () и file.toURI (), и обнаружил, что 99% времени уходит на эти 3 вызова. 3 звонка, которые мне действительно нужно сделать ...

Разница для 1000 файлов составляет 15 мс по сравнению с 1800 мс на сервере. Сканирование пути сервера в Java смехотворно медленно. Если нативная ОС может быстро сканировать ту же папку, почему не может Java?

В качестве более полного теста я использовал WineMerge на XP, чтобы сравнить дату изменения и размер файлов на сервере с локальными файлами. Это повторялось по всему дереву каталогов из 33 000 файлов в каждой папке. Общее время 7 секунд. Ява: более 5 минут.

Таким образом, первоначальное утверждение и вопрос от ОП верны и действительны. Это менее заметно при работе с локальной файловой системой. Локальное сравнение папки с 33 000 элементов занимает 3 секунды в WinMerge и 32 секунды локально в Java. Итак, опять же, Java в сравнении с нативным - это 10-кратное замедление в этих элементарных тестах.

Java 1.6.0_22 (последняя версия), гигабитная локальная сеть и сетевые подключения, ping менее 1 мс (оба в одном коммутаторе)

Ява медленная


2
По-видимому, это также зависит от ОС. При выполнении того же java-приложения с той же папкой из OS X с использованием samba потребовалось 26 секунд, чтобы перечислить все 33 000 элементов, размеров и дат. Значит, сетевая Java в Windows работает медленно? (OS X была также Java 1.6.0_22.)
Бен Спинк

2

Из теста GHad есть несколько проблем, о которых упоминали люди:

1> Как упомянуто BalusC: в этом случае выполняется stream.available ().

Поскольку available () возвращает оценку количества байтов, которые могут быть прочитаны (или пропущены) из этого входного потока без блокировки при следующем вызове метода для этого входного потока.

Итак, 1-й, чтобы удалить URL этот подход.

2> Как отметил StuartH - порядок выполнения теста также влияет на кэш, поэтому устраните его, запустив тест отдельно.


Теперь начните тестирование:

Когда КАНАЛ один запускается один:

CHANNEL sum: 59691, per Iteration: 238.764

Когда ДЛИНА одна бежит одна:

LENGTH sum: 48268, per Iteration: 193.072

Похоже, что ДЛИНА является победителем здесь:

@Override
public long getResult() throws Exception {
    File me = new File(FileSizeBench.class.getResource(
            "FileSizeBench.class").getFile());
    return me.length();
}
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.