SE
Из забавного: Embarcadeo (бывший компилятор Borland) зашевелился и теперь шлёт патчи в Boost (последняя официально оттестированная на Boost версия Borland была ~40 релизов назад)
так они ж на основе шланга щас делают вроде
Size: a a a
2020 August 15
AP
так они ж на основе шланга щас делают вроде
Ну у них и патчи - уберите этот workaround, он больше не нужен
AN
так они ж на основе шланга щас делают вроде
Лол что. На основе шланга? То есть по сути там их только всякие штуки rad итд
SE
Лол что. На основе шланга? То есть по сути там их только всякие штуки rad итд
AN
Дропнцли свой компилер
AD
есть некий сервис на С++, который состоит из множества частей. Хотелось бы понимать в разные моменты времени, какие части приложения сколько выжрали оперативной памяти. То есть организовать достаточно детализированный профайлинг памяти для приложения.
Сейчас регулярно снимается стастика с аллокатора (jemalloc), но понятное дело, что это говорит только о ситуации для всего приложения.
Есть идеи, как подобное организовать?
Первое, что мне приходит в голову - разным частям приложения раздать разные аллокаторы и зафорсить по крайней мере для начала административно их использование в различных подсистемах приложения. Ну или свой аллокатор с какими-то метками для каждой части приложения, которые при аллоках\деаллоках будет заниматься подсчётом нужной статистики.
Почему не используются готовые утилиты профайлинга - они не дают нужной точности.
Если важно - С++14
Сейчас регулярно снимается стастика с аллокатора (jemalloc), но понятное дело, что это говорит только о ситуации для всего приложения.
Есть идеи, как подобное организовать?
Первое, что мне приходит в голову - разным частям приложения раздать разные аллокаторы и зафорсить по крайней мере для начала административно их использование в различных подсистемах приложения. Ну или свой аллокатор с какими-то метками для каждой части приложения, которые при аллоках\деаллоках будет заниматься подсчётом нужной статистики.
Почему не используются готовые утилиты профайлинга - они не дают нужной точности.
Если важно - С++14
Вай нот наколхозить макрос который на каждую аллокацию рисует переменная по ключу $x увеличся? В жапке такое легко делается агентами
AZ
Вай нот наколхозить макрос который на каждую аллокацию рисует переменная по ключу $x увеличся? В жапке такое легко делается агентами
и как мне этот макрос прокинуть внутрь
std::vector?m
и как мне этот макрос прокинуть внутрь
std::vector?А все-таки, чего именно нужно добиться? Достаточно ли получить стэктрейсы всех аллокаций? Или нужно именно расставить тэги для каждой подсистемы?
AD
и как мне этот макрос прокинуть внутрь
std::vector?Да никак, поверх.
DF
Стектрейс аллокации покажет и размер кстати
DF
Потом агрегировать можно етот лог
DF
Правда удобно ли будет определить по нему подсистему с нужной гранулярностью
AP
есть некий сервис на С++, который состоит из множества частей. Хотелось бы понимать в разные моменты времени, какие части приложения сколько выжрали оперативной памяти. То есть организовать достаточно детализированный профайлинг памяти для приложения.
Сейчас регулярно снимается стастика с аллокатора (jemalloc), но понятное дело, что это говорит только о ситуации для всего приложения.
Есть идеи, как подобное организовать?
Первое, что мне приходит в голову - разным частям приложения раздать разные аллокаторы и зафорсить по крайней мере для начала административно их использование в различных подсистемах приложения. Ну или свой аллокатор с какими-то метками для каждой части приложения, которые при аллоках\деаллоках будет заниматься подсчётом нужной статистики.
Почему не используются готовые утилиты профайлинга - они не дают нужной точности.
Если важно - С++14
Сейчас регулярно снимается стастика с аллокатора (jemalloc), но понятное дело, что это говорит только о ситуации для всего приложения.
Есть идеи, как подобное организовать?
Первое, что мне приходит в голову - разным частям приложения раздать разные аллокаторы и зафорсить по крайней мере для начала административно их использование в различных подсистемах приложения. Ну или свой аллокатор с какими-то метками для каждой части приложения, которые при аллоках\деаллоках будет заниматься подсчётом нужной статистики.
Почему не используются готовые утилиты профайлинга - они не дают нужной точности.
Если важно - С++14
Там у jemalloc есть особый режим профилировки, он выдаёт достаточно подробную инфу о том, кто сколько сейчас держит памяти, кажется с трейсами. Включается какими-то рантайм флагами
AP
Смогу вечером посмотреть поподробнее, как это делается
AZ
Смогу вечером посмотреть поподробнее, как это делается
было бы неплохо - спасибо
AZ
Да никак, поверх.
просто это вариант со своими аллокаторами, который уже обсуждали выше
AZ
А все-таки, чего именно нужно добиться? Достаточно ли получить стэктрейсы всех аллокаций? Или нужно именно расставить тэги для каждой подсистемы?
если по ним возможно нормально восстановить время, место аллокаций и разбить на подсистемы, то наверное ок
AZ
другой вопрос, надо будет подумать, как шаманить и приводить в нормальный вид эти самые трейсы
AP
просто это вариант со своими аллокаторами, который уже обсуждали выше
Во, смотри utrace в http://jemalloc.net/jemalloc.3.html
И дальше смотри utrace , например https://gist.github.com/git-blame/6de0085bb9fbc4b7bc31f5c4d83f12a3
И дальше смотри utrace , например https://gist.github.com/git-blame/6de0085bb9fbc4b7bc31f5c4d83f12a3
m
если по ним возможно нормально восстановить время, место аллокаций и разбить на подсистемы, то наверное ок
Вообще можно переопределить глобальный
operator new (и delete) и в нем писать лог и форвардить вызов в jemalloc. Естественно там можно и трейс снять, и размер. С тэгами подсистем сложнее, но если точек входа в подсистему немного, можно в них проставлять в thread local переменную свой тэг и в operator new его использовать при логировании.