Python: лучше файл I / 0, используя os.fork?

Question

Моя проблема довольно проста: у меня есть файл размером 400 МБ, заполненный 10 000 000 строк данных. Мне нужно перебирать каждую строку, что-то делать и удалять строку из памяти, чтобы избежать переполнения ОЗУ.

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

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

for line in open('/data/workfile', 'r'):

Answer 1

Предлагаемый вами for line in open('/data/workfile', 'r'): будет использовать генератор, поэтому весь файл не будет считан в память. Я пошел бы с этим, пока это фактически не оказывается слишком медленным.

Answer 2

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

Answer 3

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

Даже если обработка действительно связана с вводом / выводом, добавление пары потоков в программу может немного помочь.

Это позволит другому потоку ожидать ввода-вывода, пока другой обрабатывает ранее прочитанные данные.

Answer 4

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

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

См. Также приближается mapReduce (однако это может быть немного излишне)