голый gdb и плюсы

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

Надо посмотреть на выхлоп. Возможно присоветую его товарищам на CI прикрутить, которые как минимум регрессии видеть хотят.

Я не большой спец в профайлинге пока-что, но в идеале хочу осилить все полезные линуховые средства, благо мне таки дали площадку где можно поиграться всласть :)

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

В принципе если в каком то локе не на i/o софт проводит много времени, это действительно непорядок. С другой стороны, пока целевые циферки для целевой платформы в норме, то и рыпаться не стоит, можно только хуже сделать.

иногда можно и нужно поиграться с приоритетами потоков. очень многое зависит от них.

Этим регулярно занимаются и без меня. Но сиё есть палка о двух концах. Как минимум инверсию приоритетов никто не отменял.

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

*потирая руки* Это точно:)

А чего есть в инстументе? И есть ли оно в открытом виде?

Полуинтерактивный фреймворк для анализа данных в корке. Красит корку на составляющие по областям, разбирает кучу (в открытом варианте пока только glibc) и т.д. В нулёвом варианте можно спрашивать что находится по конкретному адресу (стек, куча, хз что ... если куча, то аллоцированный блок или нечно иное), посмотреть как что покрашено, поделать выборки блоков памяти по различным критериям.

Остальной функционал нужно писать рукмми. Если это плюсовый проект, то можно, например, обойти все блоки кучи и по vptr указателям составить примерную статистику по некоторым типов объектов. Или можно определять не ссыляется ли случайно где-то указатель на уже освобождённый кусок кучи. Что удаётся более-менее причесать и обобщить докидываю в код проекта.

Использовал его примерно для таких же задач как и у тебя: был древний проект 10-15 летней давности с кучей кода и кучей сервисов (некогда известный мессенджер), случались странности разного рода (просто падения, распределённые race condition, всякие несогласованности, утечки памяти...) и нужно было как-то с этим бороться.

Звучит очень мило:)

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

Спасибо.

Понял что в хедпосте не хватает слов про фреймворк для gdb.

Сразу нагуглилось похожее решение. На сколько я могу судить пока особо не копал.

Отладочная печать в любом коде хороша.

ответ на оп-пост... для этого есть питон: https://sourceware.org/gdb/wiki/PythonGdbTutorial

в том числе тебе уже посоветовали пару написанных на нём скриптов с github-а

но искать проблемы производительности с помощью отладчика — это звучит свежо и инновационно.

для этого (особенно полезно если плохо ориентируешься в коде проекта) уже придумали профилировщики. от деревянного gprof до intel vtune.

Всё верно говоришь. Однако, в конкретном случае, столкнулся с конкретной задачей, и понял что инструменты под неё надо в любом случае кодировать. Вот интересно было послушать best practices. Оказалось, что пользуется сим 2.5 человека в интернете, что как бы намекает, что не факт что и оно мне надо.