Если бы дело было на собеседовании, кандидат бы не прошел, потому что:
— не обеспечивается индикация прогресса (прогнозируемое время и проделанная доля работы)
— не обеспечивается возможность прерывания процесса
— обработка файлов не проводится параллельно
Везде рекламируется, что преимущество async/await в отличие от BackgroundWorker
в том, что их можно использовать рекурсивно.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я совершенно не удовлетворён вот этим решением: ЭФ>https://rosettacode.org/wiki/Walk_a_directory/Recursively#C.23
Если честно, я тоже.
ЭФ>Если бы дело было на собеседовании, кандидат бы не прошел, потому что: ЭФ>- не обеспечивается индикация прогресса (прогнозируемое время и проделанная доля работы)
А за счет чего оценивать прогнозируемое время? Дополнительным проходом?
ЭФ>- не обеспечивается возможность прерывания процесса
В любой момент прерывается из вышестоящего цикла.
ЭФ>- обработка файлов не проводится параллельно
Никто не мешает обрабатывать файлы параллельно (для чего это делать?). Тут они лишь перебираются. И замечательно, что перебираются не параллельно. Взаимодействие с файловой системой не заточено для параллельной работы с каталогами.
В остальных примерах тоже не видно параллельной обработки. Зачем она нужна в примерах?
ЭФ>Везде рекламируется, что преимущество async/await в отличие от BackgroundWorker ЭФ>в том, что их можно использовать рекурсивно.
Причем тут обход директорий?
ЭФ>Ну вот, это и нужно продемонстрировать.
Нужно было продемонстрировать рекурсивный обход.
Постановка задачи вполне однозначна "Walk a given directory tree and print files matching a given pattern.".
S>Постановка задачи вполне однозначна "Walk a given directory tree and print files matching a given pattern.".
Ну это неправильная/неполная постановка, поэтому я буду обсуждать ту, которая у меня.
S> В любой момент прерывается из вышестоящего цикла.
Там ещё пермишены на файлах не обрабатываются, а на директориях обрабатываются. Неконсистентно.
А ещё советуют избегать обработки исключений, если можно обойтись проверкой.
В данном случае проверять — есть ли доступ на пролистывание директории
S> за счет чего оценивать прогнозируемое время?
Индикация прогресса разбивает процесс обхода на кусочки.
Их количество можно считать параллельно с обработкой файлов.
S> Взаимодействие с файловой системой не заточено для параллельной работы с каталогами.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я совершенно не удовлетворён вот этим решением: ЭФ>https://rosettacode.org/wiki/Walk_a_directory/Recursively#C.23
ЭФ>Если бы дело было на собеседовании, кандидат бы не прошел, потому что:
Я думаю вы с кандидатом были бы солидарны в этом вопросе
ЭФ>- не обеспечивается индикация прогресса (прогнозируемое время и проделанная доля работы)
Что бы спрогнозировать время и узнать проделанную долю работы нужно знать "целый" объем — сколько директорий/файлов будет.
А этой информации нет априори, она появится только по факту выполнения работы. Поэтому в общем случае это твое требование ~ несколько эксцентричное.
ЭФ>- не обеспечивается возможность прерывания процесса
Достаточно добавить в цикл while что-то в духе && isNotCansel и вот тебе возможность прерывания процесса.
ЭФ>- обработка файлов не проводится параллельно
Эта задача в которой параллельность оправдана довольно редко. Оверхейд на когерентность работы будет большим, а временной выигрыш маленький.
ЭФ>Везде рекламируется, что преимущество async/await в отличие от BackgroundWorker ЭФ>в том, что их можно использовать рекурсивно.
В твоём примере нет ни async/await, ни BackgroundWorker, ни даже рекурсии
m2l> Что бы спрогнозировать время и узнать проделанную долю работы нужно знать "целый" объем — сколько директорий/файлов будет.
Это не так.
m2l> появится только по факту выполнения работы.
Чтобы спрогнозировать, нужно в какой-то момент времени между началом и окончанием работы
сравнить количество уже посчитаных с количеством уже обработанных и умножить на прошедшее время обработки.
m2l> временной выигрыш маленький.
А удобство пользователя?! Крайне, крайне эгоистичный кандидат, только о своих выигрышах думает.
m2l>В твоём примере нет ни async/await, ни BackgroundWorker, ни даже рекурсии
Стек там есть. Программный. А аппаратный может быть быстрее работал бы.
D> у вас спецконтроллер для SSD, заточенный на параллельную обработку файлов, на том же дворе?
Это было бы чудесно, но это не обязательно.
Достаточно того, что нет затрат на метания механических головок.
Это достаточный повод для перевода этого кода на многпооточность.
Это личное дело каждого — где и по какому поводу кидать понты. Задача решена, но проблема в ней вовсе не в "индикации прогресса":
Task: Walk a given directory tree and print files matching a given pattern.
Note: This task is for recursive methods.
Проблема сишарпового решения — оно не использует рекурсию, как указано в замечании. Хотя на мой взгляд, без рекурсии как раз эффективнее.
ЭФ>Если бы дело было на собеседовании...
И с чего ты решил, что на собеседовании будут требовать пункты, которые ты перечислил?!!
ЭФ>Везде рекламируется, что преимущество async/await в отличие от BackgroundWorker ЭФ>в том, что их можно использовать рекурсивно.
ЭФ>Ну вот, это и нужно продемонстрировать.
Это тебе нужно понтануться вчера прочитанной статьёй, а для каталогов задача решена верно. Чё прикопался к столбу?? Больше не нашёл места понты кидать?
Здравствуйте, Эйнсток Файр, Вы писали:
m2l>> Что бы спрогнозировать время и узнать проделанную долю работы нужно знать "целый" объем — сколько директорий/файлов будет. ЭФ>Это не так.
m2l>> появится только по факту выполнения работы. ЭФ>Чтобы спрогнозировать, нужно в какой-то момент времени между началом и окончанием работы ЭФ>сравнить количество уже посчитаных с количеством уже обработанных и умножить на прошедшее время обработки.
Ничерта не понял. Что такое "количество посчитанных" и что такое "количество обработанных"? Как вы сделаете прогресс сами?
m2l>> временной выигрыш маленький. ЭФ>А удобство пользователя?! Крайне, крайне эгоистичный кандидат, только о своих выигрышах думает.
Если будет задача написать супер пупер энумератор, то тут одной попытки мало. Дайте денек, тогда и будет супер пупер энумератор.
А тут вполне нормально написано. Я бы к такому год не возвращался, тем более что он проходит дерево лениво и не жрет кучу памяти.
m2l>>В твоём примере нет ни async/await, ни BackgroundWorker, ни даже рекурсии ЭФ>Стек там есть. Программный. А аппаратный может быть быстрее работал бы.
ЭФ>Мало ли, что нет, можно добавить.
Здравствуйте, Эйнсток Файр, Вы писали:
D>> у вас спецконтроллер для SSD, заточенный на параллельную обработку файлов, на том же дворе?
ЭФ>Это было бы чудесно, но это не обязательно. ЭФ>Достаточно того, что нет затрат на метания механических головок. ЭФ>Это достаточный повод для перевода этого кода на многпооточность.
вовсе нет...
заявленная многопоточность будет жрать ресурсы, в то время как вся работа с файлами будет выполняться последовательно "козе баян?"
ОК, с одним из трех твоих недостатков разобрались. Осталось два.
m2l>> появится только по факту выполнения работы. ЭФ>Чтобы спрогнозировать, нужно в какой-то момент времени между началом и окончанием работы ЭФ>сравнить количество уже посчитаных с количеством уже обработанных и умножить на прошедшее время обработки.
ОК, я переформулирую задачу под твой ответ:
В директории неизвестное число вложенных файлов и директорий — N штук.
Ты потратил 100 мс и насчитал и обработал допустим 200 директорий и 200 файлов.
Сколько времени тебе нужно, что бы закончить обработку оставшегося неизвестного числа файлов и директорий?
PS. Число (мили)секунд, директорий и файлов может подставить по своему усмотрению.
m2l>> временной выигрыш маленький. ЭФ>А удобство пользователя?! Крайне, крайне эгоистичный кандидат, только о своих выигрышах думает.
Ты забыл процитировать мои слова про плохое распараллеливание и большой оверхейд.
В идеальном случае временной выигрыш будут 1,2-1,3 раза. Но при этом суммарная нагрузка на процессор вырастет раз в 6-8. Причем этот временной выигрыш — верхняя граница, а расход тактов будет с тобой так сказать всегда.
Ну и как часто при обходе директорий такой сценарий оправдан?
m2l>>В твоём примере нет ни async/await, ни BackgroundWorker, ни даже рекурсии ЭФ>Стек там есть. Программный. А аппаратный может быть быстрее работал бы.
Я бы написал такой код с рекурсией, но это не отменяет вопроса что тебя возмущает.
ЭФ>Мало ли, что нет, можно добавить.
Зачем? Время работы это только увеличит.
m2l>Ты потратил 100 мс и насчитал и обработал допустим 200 директорий и 200 файлов. m2l>Сколько времени тебе нужно, что бы закончить обработку оставшегося неизвестного числа файлов и директорий?
Я ещё насчитал к этому моменту в 100 мс 500 директорий всего суммарно, потому что мой код параллельный.
А ты не насчитал, потому что твой код последовательный.
m2l>Зачем? Время работы это только увеличит.
И удобство пользователя тоже. Идти пить чай или нет, вот в чём вопрос.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я ещё насчитал к этому моменту в 100 мс 500 директорий всего суммарно, потому что мой код параллельный. ЭФ>А ты не насчитал, потому что твой код последовательный.
Молодец, так прогресс то какой? Сколько времени осталось?
m2l>>Зачем? Время работы это только увеличит. ЭФ>И удобство пользователя тоже. Идти пить чай или нет, вот в чём вопрос.
Всё же разберись удобство в том что программа быстрей или медленней работает. А то в одним сообщениях так, в других наоборот... Будь последователен
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>И удобство пользователя тоже. Идти пить чай или нет, вот в чём вопрос.
причем тут чай?
распараллеливание тупо подвесит пользователю ютуб — где же тут удобство?
ЭФ>>Я ещё насчитал к этому моменту в 100 мс 500 директорий всего суммарно, потому что мой код параллельный. ЭФ>>А ты не насчитал, потому что твой код последовательный.
m2l>Молодец, так прогресс то какой? Сколько времени осталось?
Прогресс 200 из 500 за 100 мс.
ETA 250 мс от момента старта
m2l>>>Зачем? Время работы это только увеличит.
Несущественно увеличит.
А удобство в том, что программа даёт прогноз.
m2l> Будь последователен
Здравствуйте, Эйнсток Файр, Вы писали:
m2l>>Молодец, так прогресс то какой? Сколько времени осталось?
ЭФ>Прогресс 200 из 500 за 100 мс.
200 + 500 из неизвестного тебе N. ЭФ>ETA 250 мс от момента старта
N = 200000 вложенных файлов и директорий. Из них ты за 100 мс прошел в сумме 700 объектов.
Фактическое время работы будет на два порядка больше твоего ETA.
N = 701 вложенных файлов и директорий. Из них ты за 100 мс прошел в сумме 700 объектов.
Фактическое время работы будет на два порядка меньше твоего ETA.
Адекватность?
ЭФ>Несущественно увеличит. ЭФ>А удобство в том, что программа даёт прогноз.
Прогноз возможен только если обходить дерево дважды. Причем при первом обходе прогноза не будет. Поэтому нигде траверс директорий не прогнозируется по времени.
ЭФ>Параллелен. Ты неубедителен.
Ну почему же. Из трех твоих претензий к примеру, от двух ты уже отказался. Прогресс есть.
m2l> N = 200000 вложенных файлов и директорий. Из них ты за 100 мс прошел в сумме 700 объектов. m2l> Фактическое время работы будет на два порядка больше твоего ETA.
Обход идёт параллельно с обработкой файлов и время будет быстро уточняться.
Поэтому ошибка на старте это не проблема.
m2l> N = 701 вложенных файлов и директорий. Из них ты за 100 мс прошел в сумме 700 объектов. m2l> Фактическое время работы будет на два порядка меньше твоего ETA.
Тут я не понял пример. Но отвечу
Если есть существенная нестабильность прогноза, например крупные файлы в последней директории,
это значит что влияющий фактор (размер файла) нужно добавить в формулу прогнозной оценки.
m2l> Адекватность?
В среднем не вижу ничего плохого.
m2l> от двух ты уже отказался.
Я сосредоточился на основном вопросе, вернуться к тем другим я всегда успею.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Обход идёт параллельно с обработкой файлов и время будет быстро уточняться.
У нас нет "обработки" файлов, если не считать проверки на соответствие условию. ЭФ>Поэтому ошибка на старте это не проблема.
Но она будет в любой момент, на старте, в середине, в конце...
Да и какая разница что за ошибка. Ты даже для одного примера не смог рассчитать это время.
Но думаешь, что сможешь написать программу, которая будет это делать.
ЭФ>Тут я не понял пример. Но отвечу ЭФ>Если есть существенная нестабильность прогноза, например крупные файлы в последней директории, ЭФ>это значит что влияющий фактор (размер файла) нужно добавить в формулу прогнозной оценки.
Ты прогнозирующий значение случайной величины с неизвестным распределением. Тебе медаль Фишера дадут за такую формулу.
m2l>> Адекватность? ЭФ>В среднем не вижу ничего плохого.
Но-но, тролинг это плохо.
Просто попробуй дополнить кусок кода из своего первого сообщения своей формулой. И проверить как она работает.
В лучшем случае на этапе реализации ты поймешь что не прав, в худшем случае когда будешь получать несоответствие прогнозируемого времени фактическому.
Потому, что: m2l>> Прогноз возможен только если обходить дерево дважды. Причем при первом обходе прогноза не будет. Поэтому нигде траверс директорий не прогнозируется по времени
m2l>> от двух ты уже отказался. ЭФ>Я сосредоточился на основном вопросе, вернуться к тем другим я всегда успею.
Можешь разнести их по тредам. Я готов параллелится.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я совершенно не удовлетворён вот этим решением: ЭФ>https://rosettacode.org/wiki/Walk_a_directory/Recursively#C.23
Ну это как бы и не тот сайт, где публикуются лучшие решения, удовлетворяющие всем возможным требованиям
Это всего лишь иллюстрация алгоритмов на разных языках.
