Чтение parent и child chains: где применять правку

Сеньор открывает pprof и видит json.Marshal на 28% CPU. Он не тянется за более быстрой JSON-библиотекой. Он проверяет parent chain. Один широкий parent: логгер запросов. Правка не в библиотеке — в логгере, который вызывает Marshal на каждом запросе независимо от уровня логирования.

Чтение parent chain

Parent chain отвечает: «откуда вызывается этот широкий leaf?»

Концентрированный fan-in (один широкий parent-путь): leaf вызывается многократно из одного места. Правь caller’а — вызывать реже, кэшировать результаты, батчить или устранить вызов.

Распределённый fan-in (много узких parents): leaf — это shared-инфраструктура, используемая многими caller’ами. Правь сам leaf, потому что оптимизация любого одного caller’а оставляет остальных девятнадцать неизменными.

Классический пример: json.Marshal широкий с одним широким путём от логгера — значит, проблема в логгере; не меняй JSON-библиотеку, чини логгер. Тот же json.Marshal широкий и вызываемый из двадцати handler’ов — значит, JSON и есть bottleneck; меняй библиотеку или pre-encode.

Production-grade pprof и Pyroscope позволяют переключаться между leaf-up и caller-down view одним кликом; использовать оба — сеньорная привычка.

Чтение child chain (self-time vs cum-time)

Child chain отвечает: «эта функция делает работу сама или делегирует callee?»

Leaf с большим self-time и узкими детьми: функция делает работу сама. Правка внутри функции.

Parent с thin self-time и широким cum-time: это диспетчер. Цена — на уровень ниже в callee. Правь callee, не этот слой.

Правило чтения: иди от leaf’а с высоким self-time вниз по parent chain. Найди уровень, где cum-time резко падает при движении вверх. Этот уровень — «граница содержательной работы» — выше диспетчеризация, ниже исполнение. Правку применяй внутри этой границы.

Неверное определение этой границы — причина переписывания middleware, оборачивающего медленный DB-вызов, или оптимизации HTTP-роутеров, когда цена в теле handler’а.

Амортизация fan-in

Когда одна функция вызывается из многих caller’ов, оптимизация leaf’а складывается по каждому caller’у. 30% локальное улучшение в shared-функции, используемой двадцатью путями, даёт 30% по каждому из путей.

Обратный случай — fan-out: один caller, бьющий по многим callees. Оптимизация каждого callee — локальное сокращение одного пути.

Сеньорный приём: смотри fan-in/fan-out shape до выбора leaf vs caller fix. Высокий fan-in (shared infra) — leaf fix амплифицируется. Высокий fan-out (один caller, много callees) — caller fix (батчинг, кэширование, устранение вызова) амплифицируется. Эта математика часто перевешивает выбор семейства правок: даже маленький fix на высоко-fan-in leaf’е может перебить большую правку на single-caller-пути.

Bottom-up vs top-down views

pprof, Pyroscope и Intel VTune поддерживают два дополняющих друг друга view.

Bottom-up: ранжирование функций по self-time, leaf-first. Лучше для поиска одной функции, съедающей больше всего CPU.

Top-down: ранжирование функций по cum-time от корня, parent-first. Лучше для поиска подсистемы, ответственной за бо́льшую часть времени.

Сеньорная привычка чтения: сначала bottom-up — назвать горячий leaf, затем top-down — увидеть, какой entry-point его держит. Leaf, горячий под одним entry-point’ом — локализованная правка; leaf, горячий под многими — shared-инфраструктура.