#video

NEED FOR SPEED

Если сравнивать C++ с другими популярными языками (Python, Java, C#, etc.), то адекватно написанные программы на нем будут почти наверняка быстрее аналогичных программ на других языках.

Однако и внутри C++ есть своя сегрегация по скорости.

(1) В стандартных проектах мало кого может удивлять использование std::shared_ptr вместо голых указателей, постоянные аллокации памяти, забытый где-то std::move. Скорее всего, фикс такого это действительно "экономия на спичках" и только будет потом мешать разработке.

(2) В не очень стандартных проектах (браузеры, компиляция) уже немного сходят с ума - используют small vector (часть вектора на стеке), статический полиморфизм (юзают CRTP вместо виртуальных функций), вместо std::string делают непонятно куда указывающие std::string_view и т.д. Это встречали многие.

(3) Но в реалтаймовых программах своя вселенная. Нельзя делать системные вызовы, блокировать поток, использовать алгоритмы сложности > O(1), и еще куча ограничений. Это обработка сигналов, звука, HFT-системы...

Про программы из класса (3) рассказывает Тимур Думлер:
https://youtu.be/8GlwkWxf3hk?t=3504
Использование стандартной библиотеки С++ для обработки сигналов в real-time

Это выступление было мне интересно, как человеку, никогда не сталкивавшимся с такими жесткими рамками 👍

#madskillz

Garbage Collector

На C++ есть проекты, где реализована сборка мусора.

Например, браузерный движок Blink (часть Chromium). Это такой монолит, где зависимости между разными объектами настолько сложные, что понимание общей картины - нереально для человека. И там есть МНОГО циклических зависимостей, потому что в какой-то момент архитектура бронзовеет и ее не переделать. Чтобы циклов не было, писали примерно так:

class A {
    RefPtr<B> m_b;
};
class B {
    A* m_a;
};

В какой-то момент всё было настолько плохо, что память протекала в 10% тестов. Решили проблему, добавив сборщик мусора. Это не особо повлияло на перф, но убрало многие протекания и краши - win!

https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6JJroM8aRP49Yf0QWznZ9jrk/edit

#advice

В любой непонятной ситуации делай шаблон

Это совет от Капитана Очевидности. Нередко в разных проектах встречаются две проблемы, которые решаются одним способом.

Пусть у нас есть метод, который принимает...

(1) Очень длинный тип, который вручную пишут полностью или через typedef.

using TBazArray = ::google::protobuf::RepeatedPtrField<Namespace::Foo::Bar::Baz>;
bool AllShallFall(const TBazArray& bazArray) { ... };

Совет - надо просто заиспользовать шаблон, тогда не придется выискивать по репозиторию, какой же тип надо точно вписать.

template<typename T>
bool AllShallFall(const T& bazArray) { ... };

(2) Передача лямбды в функцию. Вряд ли кто-то передает их как "ссылку на функцию" (а я их без Интернета не напишу), поэтому могут заиспользовать std::function. Он плох тем, что аллоцирует память в стеке, и вообще лишнее звено.

bool AllShallFall(std::function<int(void)> callback) { ... };
// ...
AllShallFall([]() { return 4; });

Совет - можно избавиться от лишнего звена и передавать "напрямую", а компилятор даже сможет заинлайнить и оптимизировать код

template<typename T> AllShallFall(T callback) { ... };
// ...
AllShallFall([]() { return 4; });

Нужно быть осторожным, если не хотите копирования больших объектов. Лямбды это объекты closure type, размер в байтах которого зависит от размера за-capture-нных данных (ссылка/указатель - 8 байт, объекты по значению - их sizeof). В примере выше именно копирование объекта closure type, хотя на это забиваем из-за того что размер 0 байт (ничего не capture-им).

Поэтому код выше можно сломать, если сделать capture некопируемого объекта

std::unique_ptr i = std::make_unique<int>(3);
auto l = [i = std::move(i)]() { return 4; };
AllShallFall(l);

Чтобы оптимизировать передачу лямбды в любых условиях, можно использовать универсальные ссылки

template<typename T> AllShallFall(T&& callback) { ... };

#video

Рефлексия в C++

C++ отличается от многих языков отсутствием рефлексии. Рефлексия это способность программы "понимать" свою собственную структуру. Например - получить имя класса, список методов, добавлять методы, и так далее.

Рефлексии в run-time не будет никогда, потому что ~95% информации из исходников после компиляции просто испаряется, и полноценная рефлексия невозможна.

Развитие рефлексии в compile-time тормозилось несовершенством compile-time вычислений, поэтому эта фича войдет не ранее C++26.

О рефлексии рассказывает её разработчик Andrew Sutton - https://youtu.be/60ECEc-URP8
Интересно, что это уже второй подход к реализации рефлексии (на основе constexpr), был еще первый вариант - на основе шаблонов.

На основе этого видео и прочих источников я писал январьскую статью про рефлексию в C++Next, которую можно почитать, если тема покажется интересной 🙂 https://habr.com/ru/post/598981/

(text below)

#compiler

Как пропатчить Clang под FreeBSD

На прошлой неделе я решил попробовать починить что-нибудь в Clang, чтобы посмотреть, как это делается. Я нашел на гитхабе несколько issue, связанных с consteval-методами, и по вечерам отправлял на ревью микрофиксы.

Всего я сделал четыре патча (каждый не более нескольких строк), их можно увидеть на скриншоте
(второй снизу патч - "пробный шар" в clang-tidy, он не считается)

Один из них за неделю успели апрувнуть, другие пока висят и будут висеть много лет их судьба неясна. Какие есть впечатления и общие факты:

(1) Открытые гитхаб-issue реально могут висеть годами, пока их кто-нибудь не починит. Этот срок, наверное, коррелирует с важностью бага, но какого-то KPI на уменьшение тикетов Clang/LLVM не держит.

(2) Официальное правило из гайда - когда отправляешь патч, ищи ревьюеров сам. По блейму, похожим тикетам, и так далее. Иногда в ревью может прилететь "волшебник на голубом вертолете", но если никто так и не отревьюил, то можно почувствовать себя в шкуре детектива по поиску людей.

(3) Ревьюеры (в моих патчах отписалось 5-6 людей) - ОЧЕНЬ опытные в C++. Погрепав их имена, можно обнаружить их среди авторов многочисленных пропозалов в стандарт, докладчиков CppCon, членов комитета по плюсам, и так далее.

(4) Тусовка контрибьюторов довольно невелика, везде ревью и обсуждения проводят по сути одни и те же люди. Если искать по какому-то конкретному направлению (например consteval), то это вообще ~2 человека, которые запиливали эту фичу в соло и кроме них никто посмотреть ревью не сможет.

В целом, результат оказался немного хуже, чем я ожидал. Вещи происходят довольно неспешно, что не может не огорчать. Но я в любом случае уважаю всех контрибьюторов, которые в свой unpaid time делают мир немного лучше.

#creepy

Reference Lifetime Extension

Сегодняшнее "стрёмное правило стандарта": если вы инициализируете константную ссылку (const T&) "временным объектом" (скорее всего rvalue), то этот временный объект не уничтожается как ему было положено, а продолжает жить ровно столько, сколько живет ссылка.

Пример в двух строках:

std::string Foo::GetName();
const std::string& name = obj.GetName(); // легально и не сломается

Наверное, самое популярное использование этого правила - дефолтные значения ссылочных аргументов

void foo(const std::string& s = "default_text");

Это правило супер легко сломать - как только вызовете метод у временного объекта (obj.GetName().data()), или если будет сделан неявный каст, и так далее.
Abseil Tip of the Week показывает больше примеров успеха и фейла.

В моем примере наличие этого правила допустило лютый баг:

class A { ... };
class B : public A { ... };

void foo(const A& a) { ... }
void foo(const B& b) {
    // ...
    foo(static_cast<A>(b));
}

Я сделал неправильный каст, который скопировал объект, а не скастил к базовому классу. Правильный каст - static_cast<const A&>(b).

Выстрел в ногу произошел, когда foo(const A& a) стал сохранять ссылку на a, чтобы потом её переиспользовать. Пока вызывался foo, ссылка была рабочей, а вот потом объект разрушился и ссылка стала висячей. Дебаг занял достаточно много времени...

#longread

Я давно ничего не писал в этот блог, поэтому решил исправиться 🐸

Сегодня я дописал на habr статью про неклассические контейнеры в C++:
https://habr.com/ru/post/664044/

Из нее вы узнаете о таких контейнерах, как static_vector, small_vector, dynamic_bitset и многих других. Рекомендую к прочтению!

#creepy

Heterogeneous Lookup

Что будет, если попытаться вызвать .find()/.contains()/etc. у ассоциативных контейнеров (std::set/std::map/unordered-версии) с ключом, который не совпадает по типу? 🤔

std::map<std::string, int> m;
// ...
if (m.contains("foobar")) { ... }

У std::map есть дефолтный компаратор третьим аргументом в шаблоне - std::less<Key>. Компаратор нужен для поиска в контейнере.

Компаратор это структура, у которой должен быть определен bool operator(); выглядит оно примерно так:

constexpr bool operator()(const Key &lhs, const Key &rhs) const {
    return lhs < rhs;
}

То есть тип аргумента должен совпадать с типом ключа. Возвращаясь к примеру в начале: "foobar" имеет тип const char[7]. Он может "разложиться" в тип const char*, быть преобразован в тип std::string_view или std::string. Поэтому, к сожалению, по overload resolution создается временной объект std::string. 💩

Проверить, что это именно так, можно через строку с кастомным аллокатором (см. определение std::string), который логирует запрос на аллокации.

using traceable_string = std::basic_string<char, std::char_traits<char>, trace_allocator<char>>;

Проверяемые строки должны быть достаточно длинными, чтобы обойти Small String Optimization и вызвать аллокацию, в моем окружении это от 16 символов - код на godbolt.

Но зачем создавать std::string, если разные строковые типы сравниваемы между собой? В C++14 проблему решили лютым костылем 🩼: сделали std::less<> = std::less<void> и переопределили std::less<void> кастомно так:

template <class Key1, class Key2>
constexpr auto operator()(Key1&& lhs, Key2&& rhs) const
    return static_cast<Key1&&>(lhs) < static_cast<Key2&&>(rhs);
}

Теперь для перфоманса нужно помнить этот хак и делать

std::map<std::string, int, std::less<>> m;

тогда лишних аллокаций не будет - код на godbolt. Это называется громким словом heterogeneous lookup.

Я не смог найти причину, почему это не сделали поведением по умолчанию. Я порылся в библиотеках с кастомными контейнерами и вижу два подхода к вопросу:
(1) homogenous lookup по умолчанию (как в STL) - пример boost::container::map
(2) heterogeneous lookup по умолчанию - пример хэш таблицы в Abseil (от Google), аналог std::unordered_map/set

Перф неплохо улучшается, пример расследования для unordered контейнеров - там цифры от 20% до 35%.

#longread

У std::unique_ptr есть минус - он аллоцирует память в куче. А что, если разработать его аналог с памятью на стеке?.. Об этом можно прочитать тут!

https://habr.com/ru/post/665632/

#madskillz

Fast Pimpl

Концепцию из статьи (насколько понял, достаточно необычную) народ принял с трудом, в комментариях было бурное обсуждение и иногда непонимание.

В комментариях затронули тему Fast Pimpl (понятия, не сильно связанного со статьей). Это как раз жутко боянистая концепция.

PImpl используется, чтобы скрыть детали реализации и/или ускорить компиляцию. До его использования код в хидере выглядит так:

#include <third_party/json.hpp>
struct Value {
    third_party::Json data_;
};

Стандартный подход заключается в замене T на std::unique_ptr<T>, потому что он разрешает использовать incomplete class:

namespace third_party { struct Json; }
struct Value {
    std::unique_ptr<third_party::Json> data_;
};

Проблема, которая из-за этого возникает - аллокация объекта в куче, это замедляет рантайм PImpl-ового варианта ⏱ Поэтому используется подход Fast Pimpl:

struct Value {
    std::aligned_storage<sizeof(T), alignof(T)> data_;
};

(вместо sizeof(T) и alignof(T) надо руками ввести нужную цифру)

То есть вместо самого объекта в структуре лежит буфер памяти под этот объект, и рулят именно им.

В интернете есть много реализаций этой идиомы (по гуглежу "Fast Pimpl"), и есть обёртки, которые хороши собой 🍬

#compiler

extern "C" - на что в действительности это влияет?

Примерно 9 лет назад я пробовал писать игры на C++. Для скриптов я использовал Lua. Он поставлялся в виде статической библиотеки (lua.lib для Windows) и header-файлов. Так как Lua написан на C и lua.lib собран компилятором C, то чтобы все слинковалось, надо было подключать хидеры так:

extern "C" {
#include <lua.h>
#include <lualib.h>
#include <lauxlib.h>
}

В то время я не понимал, почему надо делать именно так. Конечно, спустя много времени стало понятно, что дело в перегрузке методов. Перегруженные методы надо как-то отличать между собой.

В языке C перегрузки методов нет, и в объектный файл попадает "чистое" название метода. В C++ попадает "запутанное", это называется name mangling:

void hello(int, char) -> hello (в С)
void hello(int, char) -> _Z1helloic (в C++)

extern "C" нужен как раз для того, чтобы методы и переменные, объявленные внутри него, имели "чистое" имя (код на godbolt)

Однако что в остальном? Сам код внутри extern "C" компилируется как C++ или как C? Мнение "C это подмножество C++" ошибочно: два языка развиваются независимо. В C есть то, чего нет в C++, например VLA.

Сам Стандарт показывает примеры, из которых видно, что код скомпилируется по правилам C++: [dcl.link] (там есть классы).

Погрепав исходники компилятора, можно точно сказать, что компиляция внутри extern "C" происходит по правилам C++, и аффектится только условие "надо манглить или нет": исходник Clang.

Вывод из этого такой: хидеры библиотеки на C должны быть достаточно простыми, чтобы в C и в C++ они компилировались одинаково.

#books

Обзор книги "Advanced C and C++ Compiling" 📚

(можно скачать тут - https://www.tgoop.com/progbook/6109)

Книги по программированию часто разочаровывают. Они подобны пирамиде - большую долю занимает элементарщина и копипаст документации в переводе Гоблина; в середине находятся менее боянистые книги, но их меньше; и на вершине находится что-то действительно интересное.

Эта книга, которую я читал в прошлом году, имеет очень большую редкость.
В ней описаны роли линкера (linker) и загрузчика (loader) и их работа в очень глубоких деталях (а также компилятора (compiler), но в меньшей степени). Есть много картинок, описаний форматов, команд Linux и Windows, и прочего.

Книга подробная вплоть до того, что объясняет, по какой схеме надо правильно версионировать свои динамические библиотеки! 🤯 (понятно, что это очень специфическое занятие)
Я бы рекомендовал для чтения первые несколько глав, а также главы 12 и 13 (для Linux-разработчиков)

#story

Как готовятся задачи к олимпиадам по программированию? (Часть 1/2)

Наверное, много кто пробовал решать задачки: на codeforces.com, школьных олимпиадах, ACM ICPC, и в других местах. Большинство людей использует C++ для решения.

Я раньше очень увлекался этим занятием (называется "проблемсеттинг"), и даже эпизодически готовил задачи для codeforces и школьных олимпиад (подготовил примерно 15-20 задач).

Это занятие оплачивается достаточно символически. Поэтому в основном этим занимаются студенты - бывшие топовые олимпиадники, которые еще не закончили университет и не нашли работу. Потом им надоедает и их сменяет другое поколение студентов.

Покажу на примере одной задачи, как происходит подготовка: Codeforces Round #704 - E. Почти отказоустойчивая база данных
(Эта задача самая сложная в том раунде, но у нее простое описание)

Как готовятся задачи к олимпиадам по программированию? (Часть 2/2)

Подготовка задачи ведется на сайте polygon.codeforces.com. Это самая продвинутая платформа, долгое время была практически единственной. Другие платформы (Яндекс.Контест, CodeChef, etc.) со временем потырили у нее фичи - валидацию, встроенную систему контроля версий, и прочее.

Для программок (генераторы, чекеры, etc.) используется библиотека testlib.h.

Процесс подготовки задачи состоит из этих пунктов (могут идти в произвольном порядке, кроме п.1):

(1) Придумывается не-баянистая идея для задачи в краткой формулировке.

(2) Создается художественное описание задачи в LaTeX - пример, это называется "легенда".

(3) Пишутся генераторы тестов, таких программок может быть несколько - пример 1, пример 2. Они могут запускаться с разными параметрами.

(4) Пишется валидатор, он нужен для проверки, что сгенерированные тесты имеют правильный формат и удовлетворяют ограничениям из условия задачи - пример.

(5) Список тестов создается через движок шаблонов Freemarker. Можно написать скрипт, который потом преобразуется в список запусков генераторов - пример из документации. В нашей задаче 100 тестов - список.

(6) Надо написать решение задачи. Есть одно эталонное правильное решение - пример, но надо также выдумать и написать все возможные неправильные решения, чтобы смотреть, смогут ли они пройти все (или почти все) тесты, и скорректировать тесты от этого.

(7) Чекер проверяет решение участника на правильность. На polygon есть дефолтные чекеры для простых задач, но если в задаче может быть несколько правильных ответов, то нужен свой чекер - пример.

Это дело достаточно серьезное, поэтому проводится перекрёстное код-ревью задач вместе с коллегами-проблемсеттерами и вычитка легенды.

Также примерно 5-15 человек разных рейтингов прорешивают задачу, не зная заранее решения. Они могут придумать неожиданное решение попроще, или заслать неправильное решение - все эти кейсы рассматриваются отдельно.

По закону больших чисел, на одну из десятков задач могут происходить факапы такого рода:

(1) Много участников додумались до решения проще авторского и реальная сложность задачи преувеличена
(2) Задача имеет слабые тесты, из-за чего проходит много "плохих" решений.
(3) Авторское решение неправильное.

Первые два типа факапов это еще ничего, а третий тип это полный треш, и на codeforces контест из-за этого просто отменяют (точнее, делают "нерейтинговым", и участвовать в нем нет смысла).

#creepy и #video

Тупое нововведение в C++23: копирование с помощью auto{}

Что нужно сделать, чтобы скопировать объект, особенно в шаблонном коде? Зная, что объявление переменной с типом auto это всегда копия, можно сделать так:

void func(const auto& something) {
    auto copy = something;
    use(copy);
}

Что, если мы не хотим объявлять новый объект, а создать копию "на месте"? Тогда можно сделать так (decay нужен потому что исходный тип может быть ссылочным и/или иметь cv-квалификаторы):

void func(const auto& something) {
    use(std::decay_t<decltype(something)>{copy});
}

А что, если мы считаем что C++ еще недостаточно сложный? То в С++23 теперь можно делать так:

void func(const auto& something) {
    use(auto{copy});
}

Эту информацию я узнал из канала "C++ Weekly": https://www.youtube.com/watch?v=5zVQ50LEnuQ В видео приводится не очень убедительный "мотивационный пример".

Комментарии к видео интереснее самого видео, все люди ловят фейспалм и пишут комментарии как "в чем вообще проблема копировать как раньше", "почему не сделали в виде std::copy", и прочее. В этом я с ними согласен!

#books

Обзор книги "API Design for C++ " 📚

(можно скачать тут - https://www.tgoop.com/progbook/3214)

Эту книгу мне когда-то посоветовал тимлид соседней команды. Он от нее был в полном восторге 🤩 Однако у меня впечатления были более сдержанными 🤔

Что такое API? По определению из книги:

An API is a logical interface to a software component that hides the internal details required to implement it.

API окружают нас везде, даже внутри одной программы их несколько. И вот книга рассматривает вопросы дизайна API на C++.

В книге довольно четко можно разделить "общие принципы дизайна API" и "специфические вопросы дизайна API на C++".

Первая составляющая, как философская, действительно очень хороша - есть много толковых идей, подсказок, и разбор API популярных проектов. Книга поможет понять, над какими вопросами думает Software Architect, чтобы API не развалился через несколько недель 👍

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

☹️ Книга издана в 2011 году, в ней описываются фичи C++0x (рабочее название стандарта C++11), но какой-то древней редакции. Нет ни слова про auto, руками пишутся std::vector<double>::iterator, и т.д.

☹️ Некоторые параграфы писал Капитан Очевидность, например Avoid #define for constants

☹️ На действительно очень важный вопрос совместимости ABI отведена буквально 1 страница с тривиальностями. Без упоминания тулзов как abidiff и каких-то специфических советов.

☹️ Про статические и динамические библиотеки отведены последние 10 страниц из 450-страничной книги, тоже с тривиальностями.

#video

Марсианские ужасы 👽

Как программист я часто имею дело с "воздушными замками": пишу код который работает с абстрактными в вакууме понятиями.

Неожиданно я наткнулся на видео, где разбирают софт для марсохода NASA (nasa/fprime). Сразу же, задыхаясь от интереса, открыл видео и принялся смотреть. Настоящей глыбой является мегадевайс, для которого писался этот код.

Первые 15 минут видео составляет унылое обозрение CI и велопарка .bash-скриптов для билда. Оттуда мы узнаем, что по авторитетной оценке анализатора lgtm.com репозиторий является редкой годнотой с качеством C/C++ кода A+.

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

В полном ужасе я обнаружил обзор на ядреную дедову смесь C89 и C++11, а от количества code smell у меня отклеились обои. Я стал свидетелем такого преступного программирования как:

Свои кривые реализации строки и вектора (буфера)

ObjBase::~ObjBase() {} // не делают ~ObjBase() = default
void resetSer(void);
ExternalSerializeBuffer(ExternalSerializeBuffer& other);
ExternalSerializeBuffer(ExternalSerializeBuffer* other);
const char* operator=(const char* src);
(void)snprintf(buffer, size, ...

В коде использование reinterpret_cast в 169 местах
Константы задаются через enum

Я думаю, надо сделать аудит NASA на предмет коррупционного сговора с lgtm.com о качестве кода. А также можно не бояться восстания машин, потому что Терминатор скорее будет страдать деменцией и стрелять себе в ноги, чем в Сару Коннор.

Комментарии к видео интереснее самого видео - работники разных European Space Agency подтверждают экстремистский уровень программирования в "научной" и "государственной" сфере.

#advice

Избыточный const снижает перфоманс ⏱

Правильное использование const это большая тема в C++. Самое крутое объяснение я видел на Const Correctness, C++ FAQ, но там не показан один из минусов "избыточного" const.

Пусть у нас есть структура, которая представляет собой API-объект. Содержимое этой структуры не планируется как-то изменять после создания, поэтому с первого взгляда логично, чтобы все поля были объявлены константными:

struct Widget {
    const std::size_t radius;
    const std::vector<Event> events;
    const Element element;
};

Но это плохо, если в коде объекты этого типа перемещаются, хранятся в векторе, и так далее.
Дело в том, что const-поля нельзя мувнуть, поэтому в записи Widget w2{std::move(w1)} поля events и element скопируются.
(пример на godbolt с логами)

Также константность полей часто просто не нужна - для нашей цели достаточно, чтобы константным был сам объект (или ссылка на него), а не его поля.

void Do(const Widget& widget);

#madskillz и #video

Успех применения идиомы Read-Copy-Update в C++

В видео За полгода - C++ Погода разработчик Яндекс.Погоды Дмитрий Старков рассказывает о переезде погодных микросервисов на C++ 🌤

До переезда Погода разрабатывалась на Node.JS + Memcached и отвечала за 300мс в 99 перцентиле. Это было медленно даже с кэшем, а после улучшения погодных предсказаний кэш стал сильно разъезжаться с реальными данными 👎🏻

Чтобы ускориться и улучшить утилизацию CPU, решили переписать на C++.
Для быстроты данные держатся in-memory, не в СУБД.

В памяти программа держит погодное состояние, которое регулярно читается (по GET-запросам от пользователей) и обновляется (по POST-запросам от поставщиков данных).

Обычный подход - shared_ptr:

std::shared_ptr<State> state;

И использование std::mutex с std::lock_guard для безопасного чтения/записи.

Более быстрый подход - использование std::shared_mutex и std::shared_lock (для читателей) и std::unique_lock (для писателей)

Однако такой подход все равно был недостаточно быстрым (в видео есть графики со "спайками"). Поэтому применили lock-free идиому Read-Copy-Update. Состояние живет тут:

std::atomic<std::shared_ptr<State>> state;

И читатель атомарно копирует объект, лежащий внутри std::atomic, прежде чем как-то с ним работать. Писатель также атомарно изменяет объект.

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

Переписывание обернулось успехом - при возросшем (за время переписывания) в 1.5 раза RPS Погода отказалась от рассинхронизирующих кэшей и стала отвечать за 30мс на 99 перцентиле! ⏱