32. Clan system: ingredients chests saving 0.144088 seconds. time Thu Apr 16 12:31:05 2026

[bylins]

2026-04-16 12:31:05.085 :: saving clan chest БУ done, timer 0.0257075260
2026-04-16 12:31:05.091 :: saving clan chest ХТЗ done, timer 0.0057508190
2026-04-16 12:31:05.122 :: saving clan chest ОС done, timer 0.0315348900
2026-04-16 12:31:05.135 :: saving clan chest ИР done, timer 0.0125733640
2026-04-16 12:31:05.191 :: saving clan chest ДНЗ done, timer 0.0556821790
2026-04-16 12:31:05.203 :: saving clan chest СС done, timer 0.0119975840
новый лог после правок
stribog@vm1:/home/mud/mud$ cat syslog | grep "saving clan chest"
2026-04-18 13:40:28.918 :: saving clan chest БУ done, timer 0.0195537350
2026-04-18 13:40:28.922 :: saving clan chest ХТЗ done, timer 0.0039294920
2026-04-18 13:40:28.939 :: saving clan chest ОС done, timer 0.0170514890
2026-04-18 13:40:28.946 :: saving clan chest ИР done, timer 0.0072886020
2026-04-18 13:40:28.985 :: saving clan chest ДНЗ done, timer 0.0388016190
2026-04-18 13:40:28.992 :: saving clan chest СС done, timer 0.0068911170
2026-04-18 13:50:29.109 :: saving clan chest БУ done, timer 0.0202764540
2026-04-18 13:50:29.113 :: saving clan chest ХТЗ done, timer 0.0042414150
2026-04-18 13:50:29.131 :: saving clan chest ОС done, timer 0.0180280950
2026-04-18 13:50:29.139 :: saving clan chest ИР done, timer 0.0078050430
2026-04-18 13:50:29.180 :: saving clan chest ДНЗ done, timer 0.0408210960
2026-04-18 13:50:29.188 :: saving clan chest СС done, timer 0.0075672520

[bylins]

[bylins]

план таков: оптимизируем write_one_object

		object->get_affect_flags().tascii(FlagData::kPlanesNumber, buf, sizeof(buf));
		proto->get_affect_flags().tascii(FlagData::kPlanesNumber, buf2, sizeof(buf2));
		if (strcmp(buf, buf2)) {
			out << "Affs: " << buf << "~\n";
		}

убираем всю подобную страхоблудину, переходим на сравнение и запись чисел.
При чтении смотрим, если это число, читаем как число, если набор буковцифер, читаем по старому.
Только std::array<Bitvector, kPlanesNumber> m_flags; надо в число превратить

[kvirund]

Решение

PR: #3174

Корень проблемы

write_one_object() вызывал tascii() 10 раз на каждый сохраняемый объект (5 групп флагов × 2: объект + прототип). Каждый вызов делал 4×30 = 120 итераций с strlen()/snprintf() на каждый установленный бит, затем strcmp() для сравнения. При большом сундуке кланового склада — тысячи объектов, тысячи вызовов.

Изменения

FlagData::to_numeric_string() — новый метод сериализации: пишет четыре значения плейнов как числа через пробел ("p0 p1 p2 p3"). Вместо цикла по битам — 4 вызова std::to_string.

FlagData::from_string() — расширен для нового формата. Если строка содержит ровно 4 числа через пробел — читает как числа напрямую. Старый ASCII-формат (a0b2 ) и старый packed-number формат продолжают работать (обратная совместимость с существующими сохранениями).

write_one_object() — блоки Affs/Anti/Nofl/Extr/Wear переписаны:

• убраны временные буферы buf/buf2
• вместо tascii + strcmp: прямое FlagData::operator!= (4 сравнения целых) + to_numeric_string() при различии

[kvirund]

Переоткрываю. После #1e61b3eb9 совокупное время «saving clan chest» упало с ~0.144 с до ~0.094 с (худший чест ДНЗ: 0.056 -> 0.039 с, ~30%). Существенно, но всё ещё много для пути, лежащего на главном треде игрового лупа.

Дальше думать предлагаю в следующем порядке:

1. Сначала — тестовый стенд (обязательно перед любыми дальнейшими оптимизациями)

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

Что предлагается

Новый бинарник bench_clan_chest_save (вариант имени — обсуждаемо), отдельная цель в CMake. Не gtest — отдельная сборка, живущая рядом с tests/:

• Генерирует синтетический чест (N объектов) с реалистичным составом полей: часть с extra_flags, affects, ex_description, skills, уникальным uid, нетривиальными vnum_zone_from.
• Или — может считать реальный .ing файл (путь аргументом) и прогнать write_one_object в цикле.
• Замеряет сериализацию write_one_object в std::stringstream (и дальше — в файл) K раз, отдаёт min/median/p95/max.
• В идеале — ещё режим round-trip: write → read → write → diff с исходным — это даст нам заодно регрессионный тест формата (ровно то, чего нам не хватало при переходе на numeric-формат флагов).

Стек:

• google-benchmark — есть смысл, если хочется стабильную методику (warmup, статистика, multi-threshold). Добавляется либо через vcpkg, либо submodule.
• Самописный harness на std::chrono — проще, достаточно для "до/после".

Я за второе на первом заходе — минимум зависимостей, быстрее собрать, а если понадобится серьёзный тюнинг с учётом кэша/ЦПУ — перейдём на google-benchmark.

Фикстура

Собрать синтетический чест из ~200-1000 объектов с разной комбинацией заполнения полей. Чем ближе к реальному распределению данных в проде (скосы по длине ex_description, количество affects на предмет, частота non-default флагов), тем показательнее. Можно напрямую скопировать один из живых .ing-файлов в tests/data/bench/ как baseline (скошенный под конкретный клан), плюс держать синтетический генератор для параметризации размера.

2. Профилирование (после стенда)

Release + -g -fno-omit-frame-pointer, perf record -F 999 ./bench_clan_chest_save, perf report --stdio. Покажет, где реально горит время. Гипотезы до профилирования (не верю им, пока не увижу):

• std::stringstream: в libstdc++ он исторически медленный. Если значимая доля времени там — замена на fmt::memory_buffer/fmt::format_to может дать процентов 30-50.
• proto_has_descr и сравнение ex_description через strcmp по каждой паре — дорого при длинных описаниях.
• Повторные вызовы proto->get_xxx_flags() и прочих геттеров прототипа (их вызывают несколько раз подряд — можно в локальные переменные).
• Флаги bloody/nosell сейчас мутируют объект (set_extra_flag/unset_extra_flag) туда-обратно. Это два вызова bitset::set + сравнение. Можно посчитать "flags to save" в локальном FlagData без модификации объекта.
• Аффекты/скиллы/extra_desc — линейные проходы по данным.

3. Возможные направления оптимизации (после профилирования)

Микро (в рамках write_one_object)

• Переписать вывод на fmt::format_to(std::back_inserter(out_buf)) вместо std::stringstream.
• Закешировать proto->get_affect_flags() etc в локалках.
• Убрать мутацию bloody/nosell — считать "что сохраняем" в копии флагов.
• Пересмотреть формат \"-экранирования и replace_str, там внутри strcpy-шный код.

Макро (в save_ingr_chests)

• Dirty-tracking: помечать чест как изменённый при put_ingr_chest/get_ingr_chest, при сохранении пропускать неизменённые. Большинство ресетов это ни в один чест не пишет — и save_ingr_chests будет стоить 0.
• Инкрементальный период: сейчас, по всей видимости, save_ingr_chests вызывается по таймеру, для всех клансов за раз. Можно размазать по тикам (по 1 клансу за тик), чтобы не копить всё в одном heartbeat-steps.
• Асинхронная запись: сериализация текста остаётся на main-thread, но file.write() + fclose() — в отдельный worker (у нас уже есть BlockingQueue, OutputThread — похожая модель). Это сложнее, но даёт конечную независимость от диска.

Структурно

• Бинарный/компактный формат чест-сохранения вместо текстового. Большой PR, отдельная задача, но порядковое ускорение возможно.

Предложение

1. Сделать стенд (ветка feat/clan-chest-bench), с маленьким README как запускать.
2. Прогнать baseline на текущем master'e, зафиксировать числа.
3. Профилировать, составить топ-3 горячих точек.
4. Делать по одному микро-оптимайзу — каждый PR с числом "до/после" из стенда.
5. После того как "микро" выжмет всё — думать про dirty-tracking, это уже архитектурный шаг.

Прежде чем начинать — оцени, нужны ли тебе какие-то конкретные циклы измерения в стенде (например, отдельно замер только write_one_object vs вместе с записью в файл), и хочешь ли ты сразу google-benchmark или достаточно самописа.