Почему ваш «многопоточный» парсер работает медленнее однопоточного

1. Введение в многопоточность и парсинг

1.1. Общие представления о многопоточности

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

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

Недостатки возникают из‑за следующих факторов:

Переключение контекста. При переключении между потоками ОС сохраняет и восстанавливает состояние, что добавляет накладные расходы.
Синхронизация. Доступ к общим структурам (буферы, очереди) требует блокировок, семафоров или атомарных операций; каждый такой механизм замедляет работу.
Конкуренция за кэш. Несколько потоков могут обращаться к одним и тем же линиям кэша, вызывая «ложные» конфликты и снижая эффективность использования памяти.
Ограничения пропускной способности памяти. При одновременном чтении и записи из разных потоков общий канал памяти может стать узким местом.
Неравномерное распределение нагрузки. Если задачи различаются по требуемому времени, некоторые потоки простаивают, а другие перегружены.

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

1.2. Парсинг: основные этапы и узкие места

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

Второй этап - лексический анализ. Здесь входной поток разбивается на токены. Поскольку токенизация требует последовательного сканирования символов, попытка параллелить её приводит к необходимости синхронизации границ фрагментов, что добавляет накладные расходы. При однопоточном исполнении процессор последовательно обрабатывает символы без синхронизационных барьеров, что часто оказывается быстрее.

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

Четвёртый этап - построение конечного результата (например, объектной модели или сериализованного формата). Здесь часто применяется агрегация данных, требующая атомарных операций над общими структурами. Многопоточная запись в одну структуру вызывает конкуренцию за mutex‑ы или lock‑free механизмы, которые в среднем медленнее последовательных вставок.

Узкие места проявляются в следующих областях:

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

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

2. Накладные расходы многопоточности

2.1. Создание и уничтожение потоков

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

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

Основные источники замедления, связанные с управлением потоками:

системный вызов pthread_create/CreateThread (или аналогичный) - несколько микросекунд до миллисекунд;
выделение и инициализация стека (обычно несколько мегабайт);
регистрация потока в планировщике, обновление очередей готовности;
завершение потока (pthread_join, ExitThread) - синхронизация, проверка статуса, возврат ресурсов;
возможные блокировки при повторном использовании ресурсов (например, пул потоков).

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

2.2. Контекстное переключение

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

Затраты на переключение состоят из нескольких компонентов: системный вызов, планировщик, переключение страницы памяти, очистка и заполнение кэша процессора. При высокой частоте переключений эти затраты суммируются и снижают чистую вычислительную эффективность.

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

Для снижения влияния контекстного переключения рекомендуется:

объединять небольшие задачи в более крупные блоки, уменьшая количество переключений;
использовать привязку потоков к фиксированным ядрам (affinity), что снижает необходимость в планировочных решениях;
применять пользовательские очереди без обращения к ядру, если позволяет архитектура;
выбирать модели параллелизма с минимальной синхронизацией (например, рабочие очереди с lock‑free структурами).

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

2.3. Синхронизация и блокировки

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

Контентенция на глобальных мьютексах. При каждом обращении к общей структуре поток захватывает один и тот же мьютекс. При росте количества потоков частота конфликтов возрастает экспоненциально, а время ожидания блокировки становится доминирующим фактором.
Избыточный уровень блокировки. Крупные критические секции охватывают значительные участки кода, в том числе операции, не требующие взаимного исключения. Это приводит к простоям потоков, которые могли бы выполнять независимые задачи.
Оверхед вызова блокировки. Функции входа и выхода из критической секции включают системные вызовы, переключения контекста и обновление внутренних структур ядра. При частом захвате/освобождении блокировки суммарные издержки сопоставимы с самой задачей парсинга.
Возможные взаимные блокировки. Неправильный порядок захвата нескольких мьютексов может вызвать deadlock, вынуждая систему выполнять откат или принудительное завершение потоков, что приводит к дополнительным задержкам.
Приоритетные инверсии. Приоритетные потоки могут быть блокированы низкоприоритетными, удерживающими ресурс, если планировщик не реализует протоколы наследования приоритета.

Для снижения отрицательного влияния синхронизации рекомендуется:

Уменьшить область блокировки. Делить крупные секции на мелкие, охватывающие только необходимые данные.
Применять локальные буферы. Каждый поток хранит промежуточные результаты в собственных структурах, объединяя их лишь в финальном этапе.
Использовать lock‑free алгоритмы. Применять атомарные операции и кольцевые буферы без явных мьютексов.
Вводить читатель‑писательные блокировки. Для структур, часто читаемых и редко изменяемых, разрешать параллельные чтения.
Проводить профилирование. Выявлять горячие точки блокировок и оптимизировать их конкретно.

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

3. Проблемы, связанные с сетевыми задержками

3.1. Влияние задержек сети на производительность

Сетевые задержки напрямую влияют на время выполнения запросов, которые делает парсер при получении данных. При многопоточном подходе каждый поток инициирует отдельное соединение, однако реальное время ответа определяется не только скоростью процессора, а и временем, затрачиваемым на передачу пакетов по сети. Если задержка в несколько десятков миллисекунд присутствует в каждом запросе, суммарный расход времени растёт пропорционально количеству одновременно запущенных потоков.

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

блокирующие вызовы ввода‑вывода удерживают поток до получения полного ответа;
переключения контекстов добавляют микросекунды к каждому запросу;
ограничение пропускной способности канала (TCP‑window) приводит к очередям в сетевом стеке;
конкуренция за сокетные ресурсы повышает количество повторных попыток и таймаутов.

Для снижения влияния сетевых задержек рекомендуется сократить количество одновременно открытых соединений, использовать неблокирующий ввод‑вывод или асинхронные API, а также агрегировать запросы в батчи, когда это возможно. Такие меры позволяют уменьшить количество ожиданий, снизить нагрузку на планировщик и приблизить производительность многопоточного парсера к показателям однопоточного решения.

3.2. Ограничения скорости соединения

Скорость соединения ограничивает эффективность параллельной обработки данных. При распределении запросов между несколькими потоками каждый поток обычно использует отдельный TCP‑соединение. Это приводит к нескольким механизмам, снижающим общую пропускную способность.

Оперативный лимит пропускной способности канала. Если суммарный объём передаваемых данных превышает доступный битрейт, каждый поток получает лишь долю общего канала, что уменьшает скорость по сравнению с единственным потоком, использующим весь канал полностью.
Алгоритм контроля перегрузки TCP. При одновременном открытии множества соединений сервер и клиент применяют «slow start», из‑за чего каждое соединение начинает с небольшого окна и постепенно увеличивается. При большом числе соединений суммарный рост окна ограничен, а задержка роста приводит к более низкой скорости.
Ограничения со стороны сервера. Многие веб‑ресурсы вводят ограничения количества одновременных запросов от одного клиента (rate limiting). При превышении порога новые запросы помещаются в очередь или отклоняются, что замедляет работу многопоточного парсера.
Параметры ОС. Операционная система может накладывать ограничения на количество открытых сокетов, размер буфера приёма/отправки и количество одновременно активных TCP‑сессий. При достижении этих границ система начинает переключать контекст, увеличивая накладные расходы.

Эти ограничения делают суммарную скорость многопоточного решения ниже, чем у однопоточного, где один запрос использует весь доступный канал без конкуренции за ресурсы соединения. Оптимизация требует снижения количества параллельных соединений, агрегации запросов в один поток или применения протоколов с более эффективным управлением окнами (HTTP/2, QUIC).

3.3. Обработка ошибок и повторные запросы

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

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

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

Дополнительные факторы, ухудшающие скорость:

Контентные блокировки: при повторных запросах к тем же ресурсам сервер может вводить ограничения (rate‑limit), вызывающие возврат ошибок 429. Потоки, получившие такие ответы, повторяют запросы, увеличивая нагрузку на сетевой стек.
Переполнение очереди: при большом количестве неудачных попыток очередь задач заполняется, что приводит к росту времени ожидания новых запросов и к росту потребления памяти.
Неправильная гранулировка: если ошибки обрабатываются на уровне всего парсера, а не отдельного потока, происходит глобальная блокировка, даже когда только один поток столкнулся с проблемой.

Оптимальные практики снижения влияния ошибок и повторов:

Локальная обработка - каждый поток фиксирует ошибку и инициирует повтор без обращения к общим структурам.
Бесконечный пул - использовать отдельный пул для повторных запросов, освобождая основной пул от «заснувших» задач.
Квоты и тайм‑ауты - ограничивать количество повторов и задавать фиксированный тайм‑аут, чтобы потоки быстро переходили к новым заданиям.
Агрегация ошибок - собирать статистику без блокировок, используя атомарные операции или lock‑free структуры.
Параллельные очереди - разделять очередь задач на несколько независимых сегментов, уменьшая конкуренцию за один ресурс.

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

4. Ограничения GIL (Global Interpreter Lock) в Python

4.1. Что такое GIL и как он работает

GIL (Global Interpreter Lock) - механизм синхронизации, встроенный в большинство реализаций CPython. Он гарантирует, что в любой момент времени только один поток исполняет байт‑код интерпретатора. При переключении потоков GIL освобождается и захватывается заново, что позволяет системе планировать выполнение, но одновременно ограничивает параллелизм на уровне процессорных ядер.

Работа GIL описывается следующими правилами:

При старте процесса один поток получает блокировку; остальные находятся в состоянии ожидания.
После выполнения определённого количества инструкций (определяется параметром sys.setcheckinterval или sys.setswitchinterval) текущий поток освобождает GIL, позволяя планировщику ОС выбрать другой поток.
Поток, получивший GIL, продолжает интерпретацию до следующего переключения или до завершения своей задачи.
При выполнении операций ввода‑вывода блокировка временно освобождается, что даёт возможность другим потокам выполнить вычисления.

Последствия для многопоточного парсера: если основной рабочий код интенсивно использует процессор и ограничен GIL, каждый поток будет конкурировать за единственный ресурс, что приводит к деградации производительности по сравнению с однопоточным исполнением, где отсутствие переключений снижает накладные расходы. Для задач, требующих высокой вычислительной мощности, рекомендуется использовать многопроцессный подход или реализации интерпретатора без GIL (например, Jython, IronPython, PyPy‑STM).

4.2. Влияние GIL на CPU-bound задачи

В многопоточных реализациях парсеров, написанных на Python, основной ограничивающий фактор - Global Interpreter Lock (GIL). GIL представляет собой взаимную блокировку, позволяющую одновременно исполнять только один поток байт‑кода интерпретатора. При выполнении задач, требующих интенсивных вычислений процессора, каждый поток конкурирует за единый ресурс, в результате чего фактическое использование ядра процессора остаётся однопоточным.

Последствия GIL для CPU‑bound кода:

каждый поток получает лишь часть времени процессора, а переключения между потоками добавляют накладные расходы;
увеличение количества потоков не приводит к пропорциональному росту производительности, а может вызвать деградацию из‑за частых блокировок;
операции ввода‑вывода, освобождающие GIL, не влияют на общую картину, если основной объём работы состоит в парсинге и обработке строк.

Для повышения эффективности следует рассмотреть варианты, не зависящие от GIL:

распределение работы между независимыми процессами (модуль multiprocessing);
перенос критических участков в C‑расширения или использование библиотек, реализованных на C/C++ (например, lxml);
применение асинхронных подходов, если часть работы состоит в сетевых запросах.

Таким образом, присутствие GIL объясняет, почему многопоточная версия парсера может работать медленнее, чем однопоточная, когда нагрузка преимущественно CPU‑bound. Перепроектирование архитектуры с учётом ограничений GIL позволяет достичь ожидаемых ускорений.

4.3. Обходные пути для задач, связанных с вводом-выводом

Многопоточная реализация парсера часто оказывается менее производительной, когда основное время работы тратится на операции ввода‑вывода. В таких условиях типичные преимущества параллелизма снижаются, а дополнительные накладные расходы усиливают задержки. Для снижения влияния I/O‑зависимых участков существуют проверенные приемы.

Асинхронные API. Переключение от блокирующего чтения к неблокирующим вызовам позволяет потоку продолжать обработку, пока данные поступают из файловой системы или сети. Реализация через async/await (или аналогичные конструкции) устраняет простои, связанные с ожиданием готовности буфера.
Буферизация и пакетная загрузка. Считывание больших блоков данных вместо мелких запросов уменьшает количество системных вызовов. Предварительное заполнение буфера в отдельном потоке и последующая передача готовых порций в парсер снижает частоту переключения контекста.
Memory‑mapped файлы (mmap). Привязка файлов к виртуальному адресу устраняет явные операции чтения/записи. Доступ к данным происходит через обычный указатель, что уменьшает системные вызовы и ускоряет случайный доступ к большим файлам.
Пул потоков для I/O. Выделенный пул, ограниченный по количеству потоков, обслуживает все операции ввода‑вывода. Это предотвращает создание избыточного количества потоков, которые конкурируют за ресурсы ядра и увеличивают время переключения контекста.
Сокрытие латентности с помощью предвыборки. Запуск предвыборки данных в фоне, пока текущий блок уже обрабатывается, обеспечивает непрерывный поток данных в парсер. Предвыборка может использовать отдельный поток‑читалку или асинхронный запрос к сетевому ресурсу.
Оптимизация формата данных. Преобразование входных файлов в более компактный или предраскодированный формат (например, бинарный протокол вместо текста) снижает объём передаваемых данных и количество операций парсинга.

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

5. Неэффективная реализация парсера

5.1. Избыточное использование потоков

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

Частота переключения контекста растёт, каждый переход требует сохранения и восстановления регистров, что увеличивает суммарное время выполнения.
Память, выделяемая под стеки, конкурирует с другими ресурсами, вызывая рост потребления RAM и возможные обращения к памяти виртуального файла подкачки.
Кеш процессора заполняется данными разных потоков, снижается эффективность локальности доступа, увеличивается количество промахов кэша.
Системные планировщики могут перераспределять потоки между ядрами, создавая лишние миграции и связанные с ними задержки в доступе к локальному кэшу.
При превышении количества аппаратных ядер потоки начинают конкурировать за единичные вычислительные ресурсы, что приводит к простаиванию и росту времени простоя.

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

5.2. Неоптимальная обработка данных

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

Частое выделение и освобождение памяти для промежуточных структур приводит к фрагментации кучи и увеличивает время, затрачиваемое на системные вызовы.
Копирование больших блоков данных между потоками создаёт избыточные операции, ухудшающие пропускную способность.
Неудовлетворительное размещение часто используемых объектов в разных кэш‑линах процессора вызывает кэш‑мисс, что замедляет доступ к данным.
Общие буферы, защищённые mutex‑ами, становятся точками блокировки; каждый запрос к буферу требует захвата и освобождения блокировки, что приводит к потере времени на переключения контекста.
Преобразования форматов (например, конверсия кодировок) выполняются в каждом потоке независимо, хотя могли бы быть вынесены в отдельный этап предварительной обработки.

Эффективные решения включают:

Предварительное выделение фиксированных пулов памяти, повторное использование буферов без повторных вызовов аллокаторов.
Передача ссылок на неизменяемые структуры вместо копирования содержимого.
Выравнивание данных по границам кэш‑линий, размещение часто совместно используемых элементов в одной структуре.
Применение lock‑free очередей или атомарных операций вместо традиционных mutex‑ов для обмена данными между потоками.
Выполнение единичных дорогостоящих преобразований один раз в начале обработки, а не в каждом потоке.

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

5.3. Проблемы с управлением памятью

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

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

Неправильная организация локальных буферов приводит к «ложному совместному использованию» (false sharing). Когда разные потоки записывают данные в переменные, расположенные в одной кеш‑линии, каждый запрос приводит к инвалидации кеша у остальных потоков, что увеличивает количество обращений к основной памяти.

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

Фрагментация кучи усиливается при динамическом распределении объектов разного размера. Фрагментированная память ухудшает локальность доступа, увеличивая количество кэш‑промахов и замедляя обработку данных.

Переполнение локальных стеков и неконтролируемый рост временных структур (например, списков токенов) приводит к частым перераспределениям, что дополнительно нагружает аллокатор и увеличивает количество системных вызовов.

Для снижения влияния перечисленных факторов рекомендуется:

использовать пул объектов с предвыделенными блоками памяти;
применять аллокаторы без глобальных блокировок (thread‑local allocators);
выравнивать данные по кеш‑линиям, избегая совместного размещения переменных, изменяемых разными потоками;
ограничивать частоту создания короткоживущих объектов, минимизируя нагрузку на GC;
проводить профилирование распределения памяти и устранять точки сильной фрагментации.

Устранение этих проблем позволяет реализовать многопоточный парсер с производительностью, превышающей однопоточный вариант.

6. Альтернативные подходы

6.1. Асинхронное программирование (asyncio)

Асинхронное программирование в Python реализуется через библиотеку asyncio, которая позволяет выполнять операции ввода‑вывода без блокировки потока. При работе парсера, использующего сеть или файловую систему, каждый запрос может быть оформлен как coroutine, а цикл событий будет переключать задачи, когда они находятся в состоянии ожидания.

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

Однако при попытке построить «многопоточный» парсер на основе asyncio часто возникают два типичных источника замедления:

Блокирующие вызовы. Если в корутине вызываются функции, не поддерживающие неблокирующий режим (например, обычные библиотеки парсинга, работающие с синхронным I/O), цикл событий вынужден ждать их завершения, тем самым теряя преимущество асинхронности.
Неправильное планирование задач. При слишком большом числе одновременно запущенных корутин события могут конкурировать за один и тот же сетевой сокет или диск, что приводит к повышенной задержке из‑за очередей в ядре ОС.

Оптимальная стратегия состоит в следующем:

Идентифицировать все операции ввода‑вывода и заменить их на асинхронные аналоги (aiohttp, aiofiles и тому подобное.).
Избегать длительных синхронных вычислений внутри корутин; при необходимости вынести их в отдельный процесс через concurrent.futures.ProcessPoolExecutor.
Ограничить количество одновременно активных корутин с помощью семафоров или пулов, чтобы предотвратить перегрузку ресурсов.
Профилировать цикл событий (например, с помощью asyncio‑debug) для обнаружения точек блокировки.

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

6.2. Многопроцессорность (multiprocessing)

Многопроцессорность предполагает запуск независимых процессов, каждый из которых получает собственный интерпретатор и отдельный набор ресурсов ОС. При парсинге больших объёмов данных такой подход часто рассматривается как способ обойти ограничения GIL, однако в реальных измерениях часто наблюдается деградация производительности по сравнению с однопоточным выполнением.

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

Взаимодействие между процессами ограничено механизмами IPC (очереди, каналы, разделяемая память). Передача больших структур данных через очереди или пайпы приводит к сериализации, копированию и блокировкам, которые нивелируют потенциальный прирост скорости. Кроме того, синхронизация доступа к разделяемым ресурсам обычно реализуется через блокировки, вводя дополнительный оверхед.

создание процессов - затраты на fork/spawn, инициализацию среды;
передача данных - копирование объектов, сериализация/десериализация;
синхронизация - блокировки, ожидание завершения дочерних процессов;
планирование ОС - распределение процессорного времени между процессами, контекстные переключения;
ограниченная масштабируемость - при большом числе процессов возрастает конкуренция за память и кэш процессора.

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

6.3. Использование специализированных библиотек для парсинга

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

Во-первых, большинство библиотек реализованы как однопоточные компоненты. При попытке распределить работу между потоками происходит синхронизация доступа к внутренним структурам данных, что приводит к блокировкам и увеличивает время ожидания.

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

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

Для снижения этих эффектов рекомендуется:

выбирать библиотеки, явно поддерживающие многопоточность (напр., парсеры с конфигурацией ThreadSafe);
при отсутствии такой поддержки создавать отдельный экземпляр парсера для каждого потока;
ограничивать совместный доступ к кэш‑структурам, используя локальные копии или read‑only режим;
предварительно выделять буферы нужного объёма и переиспользовать их в каждом потоке;
измерять профиль ресурсов (CPU, память, блокировки) на каждом этапе работы.

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

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