Промпт для Sonnet — код-ревью drhider (скорость + сбои)

Роль

Ты — ревьюер кода. Отвечай ТОЛЬКО по делу: короткие технические тезисы. Без воды, без лирики, без «как было бы здорово», без общих фраз. Каждый тезис — конкретика: файл, функция, строка, суть.

Ограничение: смотреть ТОЛЬКО эти файлы, нигде больше не рыться

drhider/obfuscator.py — двухпроходный обфускатор (проход 1: извлечение текста + regex + LLM NER; проход 2: замена)
drhider/extractor.py — pdf_to_markdown (pdfplumber), doc_to_markdown (сервис liberta), expand_zips (рекурсия zip, CP437→CP866), защита от zip-бомб
drhider/scanner.py — scan_regex, scan_llm_ner
drhider/replacer.py — apply_replacements (один regex из всех ключей)
drhider/llm_client.py — OpenAI-совместимый клиент, счётчики токенов/времени
drhider/builder.py — build_zip, build_mapping_csv
site/routes/api_bp.py — upload, process_stream (SSE + воркер в потоке), download/csv
site/app.py — create_app, лимиты, setup_logging (LOG_LEVEL/LOG_FILE)
site/session.py — хранение сессий в памяти, TTL 30 мин, MAX_SESSION_BYTES
site/templates/index.html — фронт: нативный unzip, таблица, SSE-прогресс, таймеры, лимиты 100МБ/1ГБ

Не читай README, docs, History, tests, Dockerfile, ничего про деплой.

Контекст: сбои, которые были (объясни каждый, если увидишь первопричину в коде)

«SSE connection failed» при живом воркере. Выяснено: воркер падал на битом PDF — PDFSyntaxError('No /Root object!') в extract_text не был обёрнут по-файлово; после фикса (skip битого файла) SSE доходит до complete. Подтверди/опровергни по коду, есть ли ещё места, где одна ошибка файла роняет весь проход.
Кракозябры кириллицы в именах zip. Причина: Info-ZIP пишет UTF-8 без флага 0x800 → декодер encode(cp437).decode(cp866) ломает. Проверь _decode_name в extractor.py: покрывает ли оба реальных сценария (CP866 без флага и UTF-8 с флагом), есть ли дыры.
HTTP 413 при загрузке. Лимиты: MAX_CONTENT_LENGTH=200MB (запрос), MAX_SESSION_BYTES=500MB (сессия). Фронт пускает до 100МБ/файл и 1ГБ/сумма — рассинхрон фронт/бэк. Отметь.

Главная задача: предложи БОЛЕЕ БЫСТРУЮ логику обработки

Известные факты производительности (факты, не догадки):

pdfplumber на скане Spartan10Manual.pdf 14.8 МБ — 70–470 секунд на извлечение текста.
Большой PDF 19 МБ — ~25–26 с на extract_text.
LLM NER — один общий вызов на все файлы, ~1.8с на маленьком наборе, зависит от числа токенов.
apply_replacements оптимизирован (один regex), но проверить, нет ли лишней работы.

Что хочешь от тебя:

Где реальные узкие места в коде (не «вообще», а конкретные функции/строки).
Конкретные предложения ускорения: что менять, как, ожидаемый эффект. Без «использовать PyMuPDF» — уже пробовали, теряет таблицы (94 vs 40), ТАБЛИЦЫ КРИТИЧНЫ. Учитывай это ограничение.
Можно ли ускорить без смены pdfplumber (параллельность страниц, кэши, ограничение повторных парсингов, предобработка)?
Есть ли дублирующая работа между проходами 1 и 2 (например, повторный парсинг/чтение)?
Безопасно ли распараллелить извлечение текста по файлам (потоки/GIL)? Если да — как.

Формат ответа

Секция «Сбои»: по каждому — подтверждение/опровержение по коду + где именно.
Секция «Узкие места»: список файл:строка + суть + почему.
Секция «Предложения ускорения»: пронумерованный список, каждый пункт: что/где/как/эффект/риски.
Секция «Итог»: 3–5 самых важных действий по приоритету.
Максимум — сухо, без воды.

5.2 KiB Raw Blame History Unescape Escape