Комментарии 14
Как я понимаю, вы проводите 2000 раз следующий цикл: «чтение файла — обработка данных». Ваш код очень неоптимален, есть несколько путей его улучшения.
— Возможно, будет быстрее сначала считать все файлы в память, а затем обработать данные. Либо считывать их по n штук, то есть, блоками.
— Имеет смысл вынести компиляцию регулярного выражения за пределы функции find_variables_in_file, поскольку каждый раз результаты компиляции, вроде, одинаковые.
— Вообще заменить регулярное выражение простым поиском вхождений getenv, GetVariable. Это нетрудно и должно сэкономить кучу процессорного времени.
— Не посылать никуда сообщение с именем переменной, а накапливать их внутри переменной, которую передать в find_variables_in_file.
— Возможно, будет быстрее сначала считать все файлы в память, а затем обработать данные. Либо считывать их по n штук, то есть, блоками.
— Имеет смысл вынести компиляцию регулярного выражения за пределы функции find_variables_in_file, поскольку каждый раз результаты компиляции, вроде, одинаковые.
— Вообще заменить регулярное выражение простым поиском вхождений getenv, GetVariable. Это нетрудно и должно сэкономить кучу процессорного времени.
— Не посылать никуда сообщение с именем переменной, а накапливать их внутри переменной, которую передать в find_variables_in_file.
Факт, компиляцию регулярного выражения можно было вынести еще выше.
Закомментировал регулярные выражения, и оно ускорилось в два раза.
Операция считывания файлов — медленна. Вполне логично делать чтение и обработку одновременной, чтобы обработка потом не занимала дополнительного времени, а проходила в те моменты, когда ожидаем прочтения следующих данных.
Читать файлы целиком смысла нет вообще, вдруг это несколько гигабайт. Нужно умело пользоваться потоками.
Читать файлы последовательно имеет смысл, учитывая свойства современных систем поддерживать файлы на винчестере одним куском. Читая параллельно даже два файла, мы бестолково мучаем винчестер.
Вообще заменить re на штатную функцию языка, которой можно гибко управлять, например, сравнение по шаблону.
Только вчера перевёл статью с аналогичным примером и обьяснением, что то, что вы тут делаете бестолково.
Читать файлы целиком смысла нет вообще, вдруг это несколько гигабайт. Нужно умело пользоваться потоками.
Читать файлы последовательно имеет смысл, учитывая свойства современных систем поддерживать файлы на винчестере одним куском. Читая параллельно даже два файла, мы бестолково мучаем винчестер.
Вообще заменить re на штатную функцию языка, которой можно гибко управлять, например, сравнение по шаблону.
Только вчера перевёл статью с аналогичным примером и обьяснением, что то, что вы тут делаете бестолково.
Простите, часть замечаний была автору.
Писать на эрланге можно и нужно, но стоит ли пихать его в каждую задачу? «Если анализ каждого файла будет более длительным...». А будет ли он более длительным? Появится ли таких файлов больше 2000? не упрется ли параллельная обработка в disk io? Такие утилиты как find оттачивались годами и понятны каждому админу, стоит ли плодить сущности?
Да, пример во многом искусственный. Но для демонстрации mapreduce весьма удобный.
Отнюдь нет. Смысл mapreduce — в распределении вычислений между разными машинами. Пытаясь распараллелить процесс на одной вы наталкиваетесь сразу на несколько грабель — попытка чтения с последовательного устройства данных вперемешку; загрузка файлов одновременно в память.
Если бы файлы лежали на трёх-четырёх машинах, это было бы ещё более-менее логично.
Если бы файлы лежали на трёх-четырёх машинах, это было бы ещё более-менее логично.
Вы очень, очень, очень сильно ошибаетесь насчёт find-а. Когда файлов становится много, нет не так, когда их становится МНОГО, find работать перестает. Это большой миф насчёт его отлаженности годами.
Годами софт отлаживали на винчестерах по 2-3 гигабайта размером. А сейчас уже 2-3 терабайта и софт типа find-а укладывает насмерть жесткий диск вместе с системой.
Да, эта софтина тоже работать не будет, потому что накапливает список файлов в памяти.
Годами софт отлаживали на винчестерах по 2-3 гигабайта размером. А сейчас уже 2-3 терабайта и софт типа find-а укладывает насмерть жесткий диск вместе с системой.
Да, эта софтина тоже работать не будет, потому что накапливает список файлов в памяти.
glob вам в помощь
Только вчера же об этом писали:
habrahabr.ru/blogs/crazydev/133697/
habrahabr.ru/blogs/crazydev/133697/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MapReduce для начинающих на Erlang'e