drhider/History/sonnet/2026-08-20-sonnet-query-honest-speed.md

Промпт для Sonnet — честный ответ: можно ли ускорить без риска устойчивости?

Роль

Отвечай ЧЕСТНО и ПО ДЕЛУ. Без воды, без лирики. Если ускорение невозможно без компромисса (устойчивость/таблицы/риск) — прямо скажи «нет» и объясни почему. Не предлагай «смену библиотеки» — уже пробовали, PyMuPDF теряет таблицы (40 vs 94), ТАБЛИЦЫ КРИТИЧНЫ для пользователя. Учитывай это ограничение железно.

ФАКТЫ (результаты наших замеров, НЕ догадки)

1. Spartan10Manual.pdf (14.8 МБ, 619 страниц, скан/руководство):
   • extract_text() суммарно = 64.4с (104мс/стр) — УЗКОЕ МЕСТО
   • extract_tables() суммарно = 0.2с (0мс/стр) — ничтожно
   • на 272 страницах без линий extract_tables = 0.0с → Твоё прошлое предположение «на сканах дорогой extract_tables» НЕ подтвердилось. Узкое место — ИЗВЛЕЧЕНИЕ ТЕКСТА, а не таблиц. Не повторяй эту ошибку.
2. Большой PDF 19 МБ (0144-03-2023_отчет об оценке.pdf, 141 стр, 94 таблицы) — ~25-26с.
3. CPU пода = 2 ядра, Memory = 4Gi. Воркер один, последовательный.
4. Разброс времени одного файла между запусками: 70с → 470с (Spartan10). Причины не установлены точно (подозрение: CPU throttling/нагрузка пода, декомпрессия битмапов).
5. .doc обрабатывается через HTTP-сервис liberta (IO-bound).
6. apply_replacements — один regex из всех ключей (уже оптимизирован).
7. Сессия хранит файлы в памяти до 500 МБ (session.py). ProcessPool с fork — риск COW-копии памяти.

Вопрос (ответь честно)

Можно ли ЗНАЧИТЕЛЬНО ускорить обработку (цель — сократить время на больших PDF/наборах), НЕ рискуя:

• устойчивостью (битые файлы, SSE, память пода 4Gi),
• потерей таблиц (критично),
• сложностью поддержки (код должен остаться понятным)?

Требования к ответу:

• Дай КОНКРЕТНЫЕ пункты, каждый: что менять / где / ожидаемый эффект (с цифрами из фактов выше) / риски.
• Раздели на: A) безопасно и просто (готов внедрить сейчас, низкий риск), B) заметный выигрыш, но с рисками/сложностью (нужен осознанный выбор), C) рискованно/не стоит (объясни почему).
• Если для БЕЗОПАСНОГО варианта реального выигрыша нет — так и скажи: «безопасно ускорить значительно нельзя», и предложи что реально можно сделать без риска (даже если эффект мал).
• НЕ предлагай смену pdfplumber/PyMuPDF и не предлагай то, что ломает таблицы.
• Оцени РЕАЛЬНО: при CPU=2 параллельность текста по страницам даст хоть что-то? (GIL/процессы, overhead fork/spawn, память). С цифрами.