Здравствуйте, Sinclair, Вы писали:
S>Я думаю, самое разумное — вызывать пользовательский делегат.
В таких случаях немеряно рулят итераторы.
S>Напрашивается решение с IEnumerable — оно позволит очень легко повторно использовать существующий код, который работает с FileInfo[]. Но я подозреваю некоторые трудности с диспозом.
Не нужно вообще возвращать FileInfo. Нужно возращать строку:
public static IEnumerable<string> GetFiles(string path)
{
string name;
while (...)
{
...
// получаем файлы по одному и возвращаем их
yalde return name;
}
}
S>По идее, надо гарантировать своевременность вызова FindClose. Но стандартный оператор foreach, насколько мне известно, использует только IEnumerable/IEnumerator.
Очень даже делает. К тому же если что финалайзер поможет.
S> Поэтому банальной реализации IDisposable вместе с IEnumerator недостаточно.
IEnumerator<T> в обязательном порядке наследуется от IDisposable!
S>Кстати, вопрос к гурам: нельзя ли это победить во втором дотнете?
Проблем небыло и в первом. Если объект реализует IDisposable, foreach всегда его дергал. Ну, а во втором... см. выше.
Да и финалайзеров никто не отменял. Перебор файлов процесс не критичный. Так что если итератор проживет на пару секунд больше никто от этого не умрет.
S>Когда будет вызван код в finally?
В конце выполнения кода. Короче, из диспоза в который будет перенесена обратотка из finally.
S> При каждом выходе по yield return?
Нет.
S>По окончанию енумерирования?
Да.
S> Что, если енумерирование будет прервано досрочно?
Будет вызван finally. Корече, все будет ОК. Итераторы — это почти полноценное континиэйшон. Так что такие вещи он обработает.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Дык используй строковый вариант. Он экономичнее.
PD>Не понял, что за строковый вариант.
Directory.GetFiles()
Возвращающая список имен файлов.
PD>Если бы только тут. Похоже, это их принципиальный подход. Шрифты хочешь перечислить — получи от InstalledFontCollection все семейства. Их, конечно, 100,000 не будет
Конечно. Так о чем тогда разговор?
PD>Во-во. Именно — если ее хватает. А в результате имеем соответствующие требования по памяти. Чего уж тут говорить, если для реализации команды dir *.* требуется 57 Мбайт!
Если у тебя проблема с памятью, то дотнет тебе просто противопаказан. Он жрет память довольно сильно. Причем сам по себе фрэймворк. Приложение может даже и не особо ее занимать. Так на машинах с большим объемом памяти (более 512 метров) второй фрэймворк банально на всякий пожарный занимает с самого начала 30 метров виртуалки. Не факт что она будет реально назначена (под нее будет отведена физическая память), но тем не менее.
Собственно что трепаться? Делаем примитивный эксперемент. Создаем пустое приложение. Ну, что-то вроде этого:
using System;
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Start...");
DateTime start = DateTime.Now;
int count = 0;
Console.WriteLine("Done " + (DateTime.Now - start)
+ " file count = " + count + "...");
Console.ReadLine();
}
}
Запускаем его и смотрим с помощью Procexp (sysinternals-овским) сколько это чудо сожрет памяти. У меня на машине плучается:
Peak working Set 4 346 K
Peak Private Bytes 7 088 K
Теперь закрываем приложение, дописываем его следующим образом:
using System;
using System.IO;class Program
{
static void Main(string[] args)
{
Console.WriteLine("Start...");
DateTime start = DateTime.Now;
int count = 0;
foreach (string s in Directory.GetFiles(@"F:\Backup\rsdn.ru\WWW\Offline\Forum"))count++;
Console.WriteLine("Done " + (DateTime.Now - start)
+ " file count = " + count + "...");
Console.ReadLine();
}
}
и натравливаем на каталог содержащий ~19 000 файлов. F:\Backup\rsdn.ru\WWW\Offline\Forum собсвтенно — это каталог с HTML-файлами RSDN Offline что кладется на наш CD.
Далее запускаем этот тест и снова смотрим расклд памяти:
Peak working Set 8 108 K
Peak Private Bytes 10 400 K
Много? Да не мало. Вот только и не смертельно учитывая что каталог не маленький.
Теперь смотрим на скорость. Да первый запуск долний. Но он не станет меньше от того что программа будет переписана на С. А второй запуск практически молниеносен:
Да, не спорю. Моя машина быстрая. Возможно твоя в 10 раз медленее и ты будешь ждать 1 секунду, но не как не две минуты про которые ты тут рассказывал. Так что если у тебя перебор файлов занимает 2 минуты, то или это время уходит на чтение с диска, или ты еще что-то делашь.
Продолжаем исследования...
Теперь переключимся на закладку ".NET" и выберем в комбе значение просмотр управяемой памяти:
Что же мы видим? Под память всех хипов домена приложения было отведено всего 3 метра! Под второе поколение (где реально и живет память) вообще выделено 12 байт. А реальная память занята только в нулевом поколении и обхем памяти составляет всего 1.3 метра. Это как раз то что нужно для выделения 19 тысяч строк.
Теперь еще раз изменим код и попробуем подсчитать сколько же памяти требует массв со строками. Каждый дотнетый объект жрет 8 байт на внутренние структуры плюс строки в дотнете юникодные, так что формула будет такая:
size += 8 + s.Length * 2;
Вставим ее в код:
using System;
using System.IO;
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Start...");
DateTime start = DateTime.Now;
int size = 0;
foreach (string s in Directory.GetFiles(@"F:\Backup\rsdn.ru\WWW\Offline\Forum"))
size += 8 + s.Length * 2;
Console.WriteLine("Done " + (DateTime.Now - start)
+ " количество байт требуемое для хранения строк = " + size + "...");
Console.ReadLine();
}
}
запустим... и получим результат:
Start...
Done 00:00:00.1093715 количество байт требуемое для хранения строк = 2106022...
Итого на хранение строк требуется 2.1 метра. Забавно, что после цикла дотнет умудряется уже освободить ее часть.
Вот теперь можно поговорить о памяти и о ужасно не эффективных алгоритмах. Как видишь в самом худшем случае мы теряем около 2 метров. Не спорю, 20 лет подряд за такой расход памяти просто убили бы. Но 20 лет назад обработка 19 тысячи файлов никак не могла бы занять одну десятую секунды. Так что мы платим за скорость и удобство самым дешевым ресурсом — памятью. А те кто не в силах расстаться со своими догмами может и дальше трахаться со всеми этими АПИ-шными наворотами.
Можно ли написать код чтения файлов более оптимально? Несомненно. Воспользуйся паттерном итератор и получишь мало чем отличимое от АПИ-шного решение. Но намногь более удобное в использовании.
Почему это не сделали? Нет необходимости. И так более чем пригодно для использования. Те сотые доли процента программистов которых не устраивает данное решение вольны написать совбстенное решение с использованием более подходящих для них паттернов. Времени на это нужно минимум. В основном оно уйдет на описание струтур АПИ. Которые, кстати, можно взять на www.pinvoke.net.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>GetFiles их этого класса возвращает массив либо всех файлов в каталоге, либо по паттерну.
PD>Могу я вместо этого получать FileInfo по одному файлу ? Мне они все вместе абсолютно не нужны.
PD>P.S. FindFirst/NextFile из Win32 я прекрасно знаю. Вопрос — если средства в самой Net Framework ?
PD>P.P.S. У меня в каталоге около 100 тысяч файлов и это от меня не зависит. Чтение каталога заняло почти минуту.
foreach(FileInfo fileInfo in directoryInfo.GetFiles())
{
...
}
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>GetFiles их этого класса возвращает массив либо всех файлов в каталоге, либо по паттерну.
PD>Могу я вместо этого получать FileInfo по одному файлу ? Мне они все вместе абсолютно не нужны.
PD>P.S. FindFirst/NextFile из Win32 я прекрасно знаю. Вопрос — если средства в самой Net Framework ?
PD>P.P.S. У меня в каталоге около 100 тысяч файлов и это от меня не зависит. Чтение каталога заняло почти минуту.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>P.S. FindFirst/NextFile из Win32 я прекрасно знаю. Вопрос — если средства в самой Net Framework ?
Можно использовать эти функции от Win32.
> GetFiles их этого класса возвращает массив либо всех файлов в каталоге, либо по паттерну. > Могу я вместо этого получать FileInfo по одному файлу ? Мне они все вместе абсолютно не нужны. > P.S. FindFirst/NextFile из Win32 я прекрасно знаю. Вопрос — если средства в самой Net Framework ?
Погоди-ка, а как ты собираешься выбрать тот файл, который тебе нужен? Если знаешь имя — создай сразу FileInfo и не мучайся.
Или хоцца просто именно перебрать файлы по одному, и по одному обработать, чтобы не было запинки на чтение всего списка? Тогда можешь последовать совету Глеба и импортировать эти функции из Kernel32.dll.
Здравствуйте, Козьма Прутков, Вы писали:
КП>Погоди-ка, а как ты собираешься выбрать тот файл, который тебе нужен? Если знаешь имя — создай сразу FileInfo и не мучайся.
Не знаю.
КП>Или хоцца просто именно перебрать файлы по одному, и по одному обработать, чтобы не было запинки на чтение всего списка? Тогда можешь последовать совету Глеба и импортировать эти функции из Kernel32.dll.
Здравствуйте, Pavel Dvorkin, Вы писали:
КП>>Или хоцца просто именно перебрать файлы по одному, и по одному обработать, чтобы не было запинки на чтение всего списка? Тогда можешь последовать совету Глеба и импортировать эти функции из Kernel32.dll.
PD>Это я и сам понял. М-да...
Щас ты еще шире скажешь "М-да..."
Согласно нашим исследованиям (а у нас до 2х млн файлов бывало) — findfirst\findnext помогут как мертвому припарки,
Что и не удивительно ибо в конце-концов что-бы ты у системы не попросил — первое что она сделает — это перечитает каталог для составления списка файлов по которому будет потом бегать. Что и займет все это время. Что-то у тебя еще быстро каталог перечитался... Минуты 2-3 — это обычное дело.
Вообщем — лучшее что мы могли придумать — это Directory.GetFiles в кэш приложения, работа с файлами из него, как опустеет — снова GetFiles.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Согласно нашим исследованиям (а у нас до 2х млн файлов бывало) — findfirst\findnext помогут как мертвому припарки,
N_P>Что и не удивительно ибо в конце-концов что-бы ты у системы не попросил — первое что она сделает — это перечитает каталог для составления списка файлов по которому будет потом бегать.
За какой такой необходимостью ? Она просто будет читать его порциями и выдавать по требованию. Разумеется, если весь каталог читать, то все кластеры придется прочитать, но если я после первых 100 файлов прекращу чтение, то остальные кластеры, занимаемые каталогом, так и не будут прочитаны. Ситуация совершенно та же, что и при последовательном чтении файла с начала.
Это во-первых. Но есть еще во-вторых. При чтении findfirst\findnext оперативной памяти мне надо — всего одна WIN32_FIND_DATA. На все 100,000 файлов. А при чтении GetFiles мне нужно памяти на массив из 100,000 FileInfo. Как говорят в Одессе, две большие разницы. Специально посмотрел по Task Manager — пока .Net программа читала этот каталог, ее Mem Usage дошло до 57 Мб.
Здравствуйте, Pavel Dvorkin, Вы писали:
N_P>>Согласно нашим исследованиям (а у нас до 2х млн файлов бывало) — findfirst\findnext помогут как мертвому припарки,
N_P>>Что и не удивительно ибо в конце-концов что-бы ты у системы не попросил — первое что она сделает — это перечитает каталог для составления списка файлов по которому будет потом бегать.
PD>За какой такой необходимостью ? Она просто будет читать его порциями и выдавать по требованию.
Подозреваю, что потому что ее программерам так проще. Хотя могу быть и не прав — но все равно проверь, сколько читается здоровый каталог через findfirst/findnext для пары файлов. Сам я .NET, но наши ребята, что на С++ сидят — говорят, что все-равно тормоза.
PD>Это во-первых. Но есть еще во-вторых. При чтении findfirst\findnext оперативной памяти мне надо — всего одна WIN32_FIND_DATA. На все 100,000 файлов. А при чтении GetFiles мне нужно памяти на массив из 100,000 FileInfo.
По GetFiles тебе надо всего-то String[100,000] под имена файлов. А потом делай что хочешь — доступ по точному имени — быстр.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Могу я вместо этого получать FileInfo по одному файлу ? Мне они все вместе абсолютно не нужны.
А чем тебя не устраивает
FileInfo fi = new FileInfo(strFilePath)
?
PD>P.S. FindFirst/NextFile из Win32 я прекрасно знаю. Вопрос — если средства в самой Net Framework ?
Гм. О каком FindNext мы говорим в контексте одного файла? PD>P.P.S. У меня в каталоге около 100 тысяч файлов и это от меня не зависит. Чтение каталога заняло почти минуту.
Не читай
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Здравствуйте, Pavel Dvorkin, Вы писали:
N_P>>>Согласно нашим исследованиям (а у нас до 2х млн файлов бывало) — findfirst\findnext помогут как мертвому припарки,
N_P>Подозреваю, что потому что ее программерам так проще. Хотя могу быть и не прав — но все равно проверь, сколько читается здоровый каталог через findfirst/findnext для пары файлов. Сам я .NET, но наши ребята, что на С++ сидят — говорят, что все-равно тормоза.
int main(int argc, char* argv[])
{
WIN32_FIND_DATA wfd;
HANDLE h = FindFirstFile("D:\\MyDir\\*.*", &wfd);
for(int i = 0; i < 100; i++)
FindNextFile(h, &wfd);
return 0;
}
Мгновенно. Mem Usage : 672 Kb. Файловая система NTFS. XP SP2 (впрочем, это не существенно)
N_P>По GetFiles тебе надо всего-то String[100,000] под имена файлов. А потом делай что хочешь — доступ по точному имени — быстр.
Всего-то навсего, да. Вот и получается 57 Мб памяти. А потом работа GC по ее освобождению.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Могу я вместо этого получать FileInfo по одному файлу ? Мне они все вместе абсолютно не нужны. S>А чем тебя не устраивает S>
S>FileInfo fi = new FileInfo(strFilePath)
S>
S>?
Есть некоторое различие между словами "одного файла" и "по одному файлу". Мне нужно именно по одному файлу : сначала первый из каталога, потом второй, потом третий и т.д. А когда это прекратить или же весь каталог прочитать — это я потом сам решу
PD>>P.P.S. У меня в каталоге около 100 тысяч файлов и это от меня не зависит. Чтение каталога заняло почти минуту. S>Не читай
Еще раз большое спасибо за исключительно ценный совет.
Здравствуйте, Pavel Dvorkin, Вы писали:
N_P>>По GetFiles тебе надо всего-то String[100,000] под имена файлов. А потом делай что хочешь — доступ по точному имени — быстр.
PD>Всего-то навсего, да. Вот и получается 57 Мб памяти. А потом работа GC по ее освобождению.
1. Ребята из MS считают что памяти у всех немеряно.
2. Каталог на 100 тыс файлов — не самая часто встречающаяся операция. Придется эту ситуацию разруливать ручками.
3. В будущем файловая система будет а-ля sql и не исключено что можно будет проходить по списку файлов ридером.
PD>Мгновенно. Mem Usage : 672 Kb. Файловая система NTFS. XP SP2 (впрочем, это не существенно)
А смысл с перебора первых 100 файлов?
PD>Всего-то навсего, да. Вот и получается 57 Мб памяти. А потом работа GC по ее освобождению.
Дык используй строковый вариант. Он экономичнее.
Хотя тут конечно писатели библиотеки накосячили. Могли бы сделать вариант с итератором или делегатом.
Ну, да напиши сам если нужно. Хотя я лично думаю, что вполне можно обойтись и строковым вариантом. Один фиг твоя идея с неполным перебором — это очередной каприз. А память... Если ее хватает, то это все ерунда. Все равно врея уходящее на чтение физического диска будет куда больше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Есть некоторое различие между словами "одного файла" и "по одному файлу".
Прошу прощения — неверно понял вопрос.
Да, такой возможности во фреймворке нет. Поэтому придется написать самому.
Есть полтора варианта:
1. Импортировать FindFirst/FindNext напрямую.
2. Отдекорировать их в соответствии с принятыми в C# соглашениями.
Я думаю, самое разумное — вызывать пользовательский делегат.
Напрашивается решение с IEnumerable — оно позволит очень легко повторно использовать существующий код, который работает с FileInfo[]. Но я подозреваю некоторые трудности с диспозом.
По идее, надо гарантировать своевременность вызова FindClose. Но стандартный оператор foreach, насколько мне известно, использует только IEnumerable/IEnumerator. Поэтому банальной реализации IDisposable вместе с IEnumerator недостаточно.
Кстати, вопрос к гурам: нельзя ли это победить во втором дотнете? Схема кода:
public IEnumerable<FileInfo> GetFiles(string mask)
{
FindFirst(...);
try
{
yield return new FileInfo(...);
while(FindNext)
{
yield return new FileInfo(...);
}
}
finally
{
FindClose();
}
}
Когда будет вызван код в finally? При каждом выходе по yield return? По окончанию енумерирования? Что, если енумерирование будет прервано досрочно?
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
PD>>Мгновенно. Mem Usage : 672 Kb. Файловая система NTFS. XP SP2 (впрочем, это не существенно)
VD>А смысл с перебора первых 100 файлов?
А просто каждый файл исследуется на предмет чего-то. Как нашли — стоп.
Да ладно, пусть не 100. Пусть все. Перебирая их по одному, я память использую в размере sizeof(WIN32_FIND_DATA). А тут получается 57 Мб.
VD>Дык используй строковый вариант. Он экономичнее.
Не понял, что за строковый вариант.
VD>Хотя тут конечно писатели библиотеки накосячили. Могли бы сделать вариант с итератором или делегатом.
Если бы только тут. Похоже, это их принципиальный подход. Шрифты хочешь перечислить — получи от InstalledFontCollection все семейства. Их, конечно, 100,000 не будет
VD>Ну, да напиши сам если нужно. Хотя я лично думаю, что вполне можно обойтись и строковым вариантом. Один фиг твоя идея с неполным перебором — это очередной каприз. А память... Если ее хватает, то это все ерунда.
Во-во. Именно — если ее хватает. А в результате имеем соответствующие требования по памяти. Чего уж тут говорить, если для реализации команды dir *.* требуется 57 Мбайт!
Здравствуйте, Andrbig, Вы писали:
A>1. Ребята из MS считают что памяти у всех немеряно.
Видимо, да.
A>2. Каталог на 100 тыс файлов — не самая часто встречающаяся операция.
Согласен, конечно.
>Придется эту ситуацию разруливать ручками.
Придется. Только вот ребята из MS еще ко всему класс DirectoryInfo сделали sealed. Так что от него наследника не сделаешь, в котором бы можно было свою функцию завести и написать ее как мне нужно. Видимо, чтобы служба медом не казалась.
A>3. В будущем файловая система будет а-ля sql и не исключено что можно будет проходить по списку файлов ридером.
Да здравствует светлое сиквеловское будущее! Ура, товарищи!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Придется. Только вот ребята из MS еще ко всему класс DirectoryInfo сделали sealed. Так что от него наследника не сделаешь, в котором бы можно было свою функцию завести и написать ее как мне нужно. Видимо, чтобы служба медом не казалась.
Да пусть они подавятся своим sealed! Напиши свой DirectoryInfo со своей структурой, с делегатами, событиями и всем, что надо. Если какому-то методу (из fw или чужой библиотеки) очень надо именно родной DirectoryInfo, то сделай метод, создающий эту пакость — пусть подавятся, а сам работай нормально с тем, что тебе надо.
PD>Да здравствует светлое сиквеловское будущее! Ура, товарищи!
Кстати, в будущем ты вкрутишь обращение к сикелю в свой DirectoryInfo и ничего менять не придется.
Здравствуйте, Andrbig, Вы писали:
A>Да пусть они подавятся своим sealed! Напиши свой DirectoryInfo со своей структурой, с делегатами, событиями и всем, что надо. Если какому-то методу (из fw или чужой библиотеки) очень надо именно родной DirectoryInfo, то сделай метод, создающий эту пакость — пусть подавятся, а сам работай нормально с тем, что тебе надо.
Можно, конечно. Включить в MyDirectoryInfo экземпляр DirectoryInfo, переписать все его методы, вызывая те, что в нем есть, из него, а свои реализуя сам. Можно... Только что-то слишком много работы для такого пустяка
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можно, конечно. Включить в MyDirectoryInfo экземпляр DirectoryInfo, переписать все его методы, вызывая те, что в нем есть, из него, а свои реализуя сам. Можно... Только что-то слишком много работы для такого пустяка
Да не так уж и много там методов. Пара часов интенсивной работы и все.
PD>>Если бы только тут. Похоже, это их принципиальный подход. Шрифты хочешь перечислить — получи от InstalledFontCollection все семейства. Их, конечно, 100,000 не будет
VD>Конечно. Так о чем тогда разговор?
Да все о том же
VD>Если у тебя проблема с памятью, то дотнет тебе просто противопаказан.
<skipped>
VD>Почему это не сделали? Нет необходимости. И так более чем пригодно для использования. Те сотые доли процента программистов которых не устраивает данное решение вольны написать совбстенное решение с использованием более подходящих для них паттернов. Времени на это нужно минимум. В основном оно уйдет на описание струтур АПИ. Которые, кстати, можно взять на www.pinvoke.net.
Влад, с тем. что ты написал, я спорить не буду. Различия у тебя и у меня могут объясняться числом файлов в каталоге, скоростью процессора, географической долготой и фазой луны . Если бы мне именно эту ситуацию надо было исследовать, я бы с удовольствием обратился к твоей помощи, и думаю, мы бы вместе разобрались бы, в чем причина столь существенных отличий. Повторя, сейчас не в этом вопрос.
Вопрос же вот в чем — мне кажется, что начал культивироваться стиль программирования, который на первое место ставит что угодно, но не эффективность. И вот это меня настораживает. Ты пишешь
>Он (фрэймворк- PD) жрет память довольно сильно. Причем сам по себе фрэймворк.
А не является ли, в частности причиной того, что он жрет память, то, что и он написан с применением такого же подхода, когда 2 Мб больше, 2 меньше — наплевать. Там наплевать, здесь наплевать, а в итоге — результат.
Очень прошу тебя — не отвечай сейчас на это мое письмо. Потому как я не удержусь и тоже отвечу , а мне не хотелось бы здесь и сейчас эту дискуссию разворачивать — ну хотя бы потому, что здесь ей просто не место. Я постараюсь в ближайшее время сформулировать свои соображения на эту тему более конкретно (наверное, в Философии), буду рад там выслушать твои замечания.
Здравствуйте, Andrbig, Вы писали:
PD>>Можно, конечно. Включить в MyDirectoryInfo экземпляр DirectoryInfo, переписать все его методы, вызывая те, что в нем есть, из него, а свои реализуя сам. Можно... Только что-то слишком много работы для такого пустяка
A>Да не так уж и много там методов. Пара часов интенсивной работы и все.
Главное не ясно зачем вообще переписывать DirectoryInfo если оно получается по имени.
Все что нужно сделать это создать класс который будет предоставлять методы перечисления возвращающие имена файлов. Далее создать по имени DirectoryInfo ничего не стоит.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Главное не ясно зачем вообще переписывать DirectoryInfo если оно получается по имени.
Охота пуще неволи. Ну охота ему не читать весь каталог в массив (даже и строк), а перебирать по одному.
Кстати, Павел! Если ты напишешь такой класс, а главное — прогонишь в своих условиях, расскажи потом насколько это было быстрее и меньше по памяти. Интересно.
VD>Все что нужно сделать это создать класс который будет предоставлять методы перечисления возвращающие имена файлов. Далее создать по имени DirectoryInfo ничего не стоит.
Это да. Вопрос в другом. Где поставить FindClose? Похоже, придется связываться с IDisposable?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вопрос же вот в чем — мне кажется, что начал культивироваться стиль программирования, который на первое место ставит что угодно, но не эффективность. И вот это меня настораживает.
А производительность и не должна быть на первом месте. Она должна быть достаточной. А на первом месте должны быть удобство и простота.
PD>Ты пишешь
PD>А не является ли, в частности причиной того, что он жрет память, то, что и он написан с применением такого же подхода, когда 2 Мб больше, 2 меньше — наплевать. Там наплевать, здесь наплевать, а в итоге — результат.
Ага. Именно что в итоге — результат! И очень даже приличный.
Я практически уверен, что при переборе по полному каталогу выигрыша не будет. Скорее всего будет примерно тоже самое, так как основное время уходит на выполнение кода ОС. Но возможно даже итераторы окажутся чуть-чуть менее эффективны. По памяти, понятно, что метра полтора-два дожно быть получше.
A>Это да. Вопрос в другом. Где поставить FindClose?
В конце! Короче, код я привел. Диспоз вроде вызывается.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Короче, код я привел. Диспоз вроде вызывается.