v0.0.55: A1 threading для .doc (liberta), A2 кэш compiled regex — безопасное ускорение

History/2026-08-20-honest-answer-and-A-implemented.md

@@ -0,0 +1,44 @@
+# 2026-08-20 — Честный ответ Sonnet об ускорении + реализация А (v0.0.55)
+
+## Честный ответ Sonnet (History/2026-08-20-sonnet-query-honest-speed.md)
+Вопрос: можно ли значительно ускорить обработку, не рискуя устойчивостью/таблицами?
+
+Ответ Sonnet (принято, согласуется с замерами):
+- **Безопасно ускорить extract_text() на pdfplumber НЕЛЬЗЯ** — pdfminer pure Python,
+  CPU-bound, GIL полностью блокирует threading. (Подтверждено: extract_text 64.4с на Spartan10.)
+- A) Безопасно-просто:
+  - A1. Threading для .doc (liberta, IO-bound) — N×~120с → ~120с при нескольких .doc.
+  - A2. Кэш compiled regex между файлами (проход 2).
+- B) Заметный выигрыш, но с рисками (ОТЛОЖЕНО):
+  - B1. ProcessPool по файлам (spawn) — 3 PDF × 25с → ~30с (только 2+ PDF, CPU=2).
+  - B2. ProcessPool по страницам (spawn) — Spartan10 64с → ~35с (сложно: content, порядок).
+- C) Не стоит:
+  - fork ProcessPool при session в памяти (COW-раздутие, 4Gi на пределе) — только spawn.
+  - Threading по страницам/файлам PDF — GIL, ноль.
+- Итог Sonnet: безопасного значительного ускорения ОДНОГО PDF нет. Для набора 2+ PDF —
+  B1. При CPU=2 потолок 2x.
+
+## Решение пользователя
+«Делай по А, безопасно» — реализованы ТОЛЬКО A1 и A2. B — НЕ отложено (не делаем).
+
+## Реализация (v0.0.55)
+
+### A1 — threading для .doc (obfuscator.py, проход 1)
+- .doc файлы (конвертация через HTTP liberta, IO-bound) запускаются в
+  ThreadPoolExecutor(max_workers=min(4, N_doc)).
+- Основной цикл сохраняет порядок: для .doc берёт future.result(), остальные —
+  последовательно. progress_cb/порядок start/done не меняются.
+- Выигрыш: HTTP-конвертация .doc перекрывается с CPU-обработкой PDF/docx.
+
+### A2 — кэш compiled regex (replacer.py + obfuscator.py)
+- replacer.py: вынесен `_build_combined_re(sorted_keys)`, `apply_replacements` получил
+  параметр `compiled_re=None` (если None — компилирует сам).
+- obfuscator.py: после формирования `self._sorted_keys` компилируется один раз
+  `self._compiled_re`, передаётся во все вызовы apply_replacements (проход 2).
+- __init__/finally: _compiled_re инициализируется/очищается.
+
+## Проверка
+- Все 106 тестов OK (test_replacer 10/10 — apply_replacements с compiled_re).
+- Интеграция: flat/ (10 файлов) → 5 обработано (EB.md, EB1.md, Spartan10, TKM, mini_78b),
+  битые пропущены, .doc через liberta в потоках. 78.3с (в основном Spartan10 64с extract_text).
+- VERSION 0.0.55.

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

@@ -0,0 +1,42 @@
+# Промпт для 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, память). С цифрами.