[Фича]: Оптимизация сохранения истории Оркестратора — готовый патч #122

Open
opened 2026-10-27 17:31:13 +03:00 by F4RK0N · 1 comment

Описание проблемы / потребности

При анализе GUI/Оркестратора обнаружены лишние операции сохранения истории: принудительный flush каждые 5 событий обходил периодическое сохранение, а обновление истории выполнялось через полный цикл чтения, нормализации и записи настроек.

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

Предлагаемое решение

В приложенном app-history.patch:

— обновление секции истории выполняется отдельной транзакцией без полной нормализации остальных настроек;
— неизменившиеся значения повторно не записываются;
— учтены согласованность кэша, ревизии и конкурентные обновления;
— удалён принудительный flush каждые 5 событий;
— сохранены периодическое сохранение, сохранение при LOCK и завершении;
— добавлены тесты сохранения истории.

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

Альтернативные варианты

No response

Дополнительный контекст / скриншоты

Базовый коммит: fceab51704.

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

Локально проверялись тесты, запуск тестовой сборки, работа с реальным winws2, ручное штатное закрытие и сохранение данных.

Ограничения: тестовые сборки использовали Python 3.12 вместо официального 3.14. Сравнение производительности предварительное: по одному прогону, в разное время и с живой сетью. Улучшение сетевых задержек не заявляется. Рабочая установка патчем не заменялась.

Проверка дубликатов

  • Я проверил существующие задачи и не нашёл аналогичного запроса
### Описание проблемы / потребности При анализе GUI/Оркестратора обнаружены лишние операции сохранения истории: принудительный flush каждые 5 событий обходил периодическое сохранение, а обновление истории выполнялось через полный цикл чтения, нормализации и записи настроек. Это создавало дополнительную нагрузку на CPU и SQLite. Подготовлен патч исходников и тесты. Прошу рассмотреть исправление для включения в ближайшее обновление. ### Предлагаемое решение В приложенном app-history.patch: — обновление секции истории выполняется отдельной транзакцией без полной нормализации остальных настроек; — неизменившиеся значения повторно не записываются; — учтены согласованность кэша, ревизии и конкурентные обновления; — удалён принудительный flush каждые 5 событий; — сохранены периодическое сохранение, сохранение при LOCK и завершении; — добавлены тесты сохранения истории. Прошу проверить реализацию и при положительном результате интегрировать её в официальный исходный код и сборку. ### Альтернативные варианты _No response_ ### Дополнительный контекст / скриншоты Базовый коммит: fceab517040b1b46fba809d97f1721b9367157fd. В архиве находятся патч, базовый коммит, сведения о проверках и контрольные суммы. Патч подготовлен с помощью ИИ и предлагается для ревью. Локально проверялись тесты, запуск тестовой сборки, работа с реальным winws2, ручное штатное закрытие и сохранение данных. Ограничения: тестовые сборки использовали Python 3.12 вместо официального 3.14. Сравнение производительности предварительное: по одному прогону, в разное время и с живой сетью. Улучшение сетевых задержек не заявляется. Рабочая установка патчем не заменялась. ### Проверка дубликатов - [x] Я проверил существующие задачи и не нашёл аналогичного запроса
Author

Дополнение по локальной проверке.

Удалось подготовить отдельную сборку с патчем на CPython 3.14.6 и восстановить TgCrypto. Изолированные selftest и GUI-smoke прошли; рабочая установка не заменялась.

Для сохранения текущих функций не хватает конфигурации:
UPDATE_SERVERS, PREMIUM_API_BASE_URL, PROXY_PRESETS и MTPROXY_LINK из config/_build_secrets.py. В частности, моя текущая установка использует Telegram-прокси с upstream-пресетом de1.

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

Предпочтительный вариант — ваша сборка с интегрированным app-history.patch. Также было бы полезно знать точный исходный коммит установленной версии Dev 21.1.7.189: в доступных метаданных его не удалось установить.

Дополнение по локальной проверке. Удалось подготовить отдельную сборку с патчем на CPython 3.14.6 и восстановить TgCrypto. Изолированные selftest и GUI-smoke прошли; рабочая установка не заменялась. Для сохранения текущих функций не хватает конфигурации: UPDATE_SERVERS, PREMIUM_API_BASE_URL, PROXY_PRESETS и MTPROXY_LINK из config/_build_secrets.py. В частности, моя текущая установка использует Telegram-прокси с upstream-пресетом de1. Подскажите, есть ли поддерживаемый способ получить публичную часть этой конфигурации для собственной локальной сборки? Секретные ключи и обход авторизации не нужны. Предпочтительный вариант — ваша сборка с интегрированным app-history.patch. Также было бы полезно знать точный исходный коммит установленной версии Dev 21.1.7.189: в доступных метаданных его не удалось установить.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
zapretdiscordyoutube/zapretgui#122
No description provided.