Получить файлы из каталога и подкаталогов быстро упорядочить по последней дате создания

Question

Получить файлы из каталога и подкаталогов быстро упорядочить по последней дате создания

1

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

До сих пор я определил следующий метод, который должен быть быстрым, но есть лучший способ сделать это, и мне нужно, чтобы он возвращал FileInfo, а не строку и упорядочивался, как описано выше.

public static IEnumerable<string> GetFileList(string fileSearchPattern, string rootFolderPath)
{
Queue<string> pending = new Queue<string>();
pending.Enqueue(rootFolderPath);
string[] tmp;
while (pending.Count > 0)
{
    rootFolderPath = pending.Dequeue();
    tmp = Directory.GetFiles(rootFolderPath, fileSearchPattern);
    for (int i = 0; i < tmp.Length; i++)
    {
        yield return tmp[i];
    }
    tmp = Directory.GetDirectories(rootFolderPath);
    for (int i = 0; i < tmp.Length; i++)
    {
        pending.Enqueue(tmp[i]);
    }
}
}

Tommy 22 авг. 2014, в 16:25

Источник

0

возможный дубликат поиска файлов в NTFS
Philip Pittle 22 авг. 2014, в 14:12

Теги:

c#

.net

3 ответа

Ещё вопросы

возможный дубликат поиска файлов в NTFS

Philip Pittle · Answer 1 · 2014-08-22T13-02-00.000Z

Когда я исследовал это проблемное пространство, я обнаружил, что это не fast способ сделать это. Причина в том, какой бы подход вы ни выбрали, вам нужно перейти в операционную систему для списка файлов в каталоге. И файловая система не кэширует/не индексирует способ поиска. Таким образом, вам в конечном итоге нужно пересканировать файловую систему самостоятельно.

Однако, если у вас есть необработанная информация, вы можете индексировать ее самостоятельно.

Matthew Brubaker · Answer 2 · 2014-08-22T12-43-00.000Z

Ниже будет работать для ваших целей. Вы хотите использовать Directory.EnumerateFiles(...), чтобы список файлов мог использовать меньше памяти спереди. Он будет искать следующий элемент, только когда вы попросите его, а не загрузите всю коллекцию в память в начале.

Directory.EnumerateFiles(rootFolderPath, fileSearchPattern, System.IO.SearchOption.AllDirectories).OrderBy(file => new FileInfo(file).CreationTime)

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

Ленивая загрузка поможет в этом отношении? ОП все равно пытается получить все файлы, поэтому отсроченное выполнение здесь не приведет к повышению производительности.
Ленивая загрузка, вероятно, не правильная формулировка. Использование EnumerateFiles (...) использует меньший объем памяти и быстрее возвращается, только когда вы действительно ищете, когда вы действительно запросите следующий элемент. Я уточнил свой ответ, чтобы указать это.

Kenny Hung · Answer 3 · 2014-08-22T12-33-00.000Z

0

Directory.GetFiles имеет возможность поиска рекурсивно.

Следующее должно работать, хотя я этого не пробовал.

    IEnumerable<FileInfo> GetFileList(string directory, string extension)
    {
        return Directory.GetFiles(directory, "*" + extension, SearchOption.AllDirectories)
            .Select(f => new FileInfo(f))
            .OrderByDescending(f => f.CreationTime);
    }

Kenny Hung 22 авг. 2014, в 12:33

0

Это неэффективное решение, потому что Directory.GetFiles () будет ждать, пока он загрузит все файлы, прежде чем вернуться. вместо этого вы должны использовать Directory.EnumerateFiles (...).
Matthew Brubaker 22 авг. 2014, в 14:13
0

Обычно я бы согласился, но мы упорядочиваем файлы по времени их создания, поэтому, возможно, нам все равно придется сначала загрузить все файлы.
Kenny Hung 22 авг. 2014, в 14:18
0

Почему? Время создания файла не изменится, и если у вас особенно большая структура папок, вы рискуете получить ошибку нехватки памяти, загружая столько строк в память. Метод LINQ OrderBy не будет оцениваться до тех пор, пока вы не запросите следующий элемент.
Matthew Brubaker 22 авг. 2014, в 14:22
0

Ах: вы поместили свое создание FileInfo в OrderBy: это действительно сэкономит вам место в памяти. К сожалению, вопрос требует возврата FileInfo, отсюда и мое решение: однако, если загрузка большой файловой структуры в память в качестве FileInfo является проблемой, то решение вашего Мэтью позволит этого избежать, но вам, вероятно, потребуется создать FileInfo дважды.
Kenny Hung 23 авг. 2014, в 21:59
0

Вы все еще можете поместить туда .Select (), эта часть не то, что экономит вашу память. Основная экономия памяти достигается за счет использования Directory.EnumerateFiles (...) вместо Directory.GetFiles (...). Directory.GetFiles (...) создаст экземпляр строки для каждого файла в коллекции сразу после выполнения. Вместо этого Directory.EnumerateFiles (...) будет создавать только строковый экземпляр, когда вы запрашиваете «следующий» файл.
Matthew Brubaker 25 авг. 2014, в 16:29
0

Я знаю, что Select () не экономит память: но OrderBy нужно будет оценить новый FileInfo (file) .CreationTime для каждого файла, поэтому вам нужно будет сохранить время создания и имя файла для каждого файла в вашем ответе, и затем повторно оцените новый FileInfo (файл) для каждого файла, когда вы перечисляете в полученном IEnumerable.
Kenny Hung 27 авг. 2014, в 20:16
0

В моем решении вам нужно будет хранить имена файлов, соответствующие им экземпляры FileInfo и время их создания для каждого файла (следовательно, используя больше памяти), но иметь окупаемость создания нового FileInfo (файла) один раз для каждого файла. Однако вы правы: если бы я использовал EnumerateFiles вместо GetFiles в своем ответе, мне пришлось бы хранить только все экземпляры FileInfo и одно имя файла за раз, чтобы таким образом сэкономить память. Однако такая ленивая загрузка редко бывает бесплатной: GetFiles с последующим упорядочением, вероятно, немного быстрее, чем EnumerateFiles с последующим упорядочением.
Kenny Hung 27 авг. 2014, в 20:24

Показать ещё 5 комментариев