Производительность PyPy3.6 с lxml.etree.iterparse и многопроцессорностью - PullRequest
0 голосов
/ 21 февраля 2019

Я создаю синтаксический анализатор xml с использованием lxml.etree.iterparse для использования памяти с небольшой нагрузкой, поскольку он будет обрабатывать довольно большие файлы, например ~ 900-3000 МБ.Его основная цель - проверить все теги с помощью набора фильтров и сохранить результаты проверки.Количество проверок сейчас составляет около 50, но оно вырастет до 150-200.Чтобы ускорить весь процесс, я разделил его на 10 процессов с многопроцессорностью (все проверки независимы, поэтому их можно запускать в любом порядке).Первые тесты с собственной реализацией CPython показывают следующие результаты для файла 16 МБ xml:

  1. ~ 5 сек.для 10 подпроцессов.
  2. ~ 13 сек.если скрипт выполняется в одном процессе и все 50 проверок выполняются одна за другой для каждого тега.

И после этого я решил попробовать PyPy для ускорения.Поскольку все фильтры написаны на чистом Python и работают с etree._Element внутри них, я подумал, что это увеличит скорость работы.Такие большие XML-файлы могут иметь миллионы строк, и каждый из них должен быть проверен 50-200 раз.И, к сожалению, все стало только медленнее.Для того же файла результаты таковы:

  1. ~ 13 сек.для 10 подпроцессов.
  2. ~ 18 сек в одном процессе.

И файл большего размера, который я беру, разрыв между PyPy и CPython только увеличивается.Для xml-файла размером 160 МБ с использованием многопроцессорной обработки CPython показывает ~ 55 сек.против ~ 267 сек.с PyPy.Более того, PyPy потребляет намного больше памяти при запуске процесса.

Это из-за того, что вызов PyPy C-кода из etree так дорого обходится?И почему он ест намного больше памяти при разборе?Или могут быть какие-то другие причины?

...