Ответ 1
Я бы подумал о добавлении грамотного выхода из программы.
У меня есть небольшое сомнение в отношении профилирующих приложений, которые никогда не выходят, пока мы не перезагружаем машину вручную.
Я использовал такие инструменты, как valgrind, который говорит об утечке памяти или вздутии любого приложения, которое выйдет после некоторого времени.
Но есть ли какой-нибудь инструмент, который можно использовать, чтобы рассказать о потреблении памяти, раздувании, накладных расходах, созданных приложением на разных этапах, если это возможно?
ПРИМЕЧАНИЕ: Мне больше интереснее знать о приложениях, которые не выходят... Если приложение выходит, я могу использовать такие инструменты, как valgrind..
Я бы подумал о добавлении грамотного выхода из программы.
точка dtrosset хорошо поставлена, но, по-видимому, неправильно понята. Добавьте средства для завершения программы, чтобы вы могли выполнить чистый анализ. Это может быть так просто, как добавление обработчика сигналов для SIGUSR1, например, который завершает программу в определенный момент времени. В зависимости от вашей операционной системы существует множество методов.
Там существует большая разница между приложением, которое никогда не выходит (встроенные, демоны и т.д.) и не может быть выведено. Предварительное нормальное явление, последнее плохое.
Во всяком случае, это приложение может быть принудительно прервано (SIGKILL on * nix, завершение на win32), и вы получите свой анализ. Этот метод не дает вашему приложению возможность очистить его до его уничтожения, поэтому, вероятно, будет сохранена сохраненная память.
Профилирование навязчиво, поэтому вы не хотите развертывать приложение с подключенным профилировщиком. Поэтому включите некоторый #ifdef PROFILE_MODE
-код, который выйдет из приложения через соответствующее количество времени. Скомпилируйте с профилем -DPROFLILE_MODE. Развертывание без PROFILE_MODE.
Измените свою программу немного, чтобы вы могли запросить проверку утечки Valgrind в любой момент - когда полученная команда будет получена, ваша программа должна использовать VALGRIND_DO_LEAK_CHECK
из memcheck.h
(это не будет иметь никакого эффекта, если программа isn 't работает под Valgrind).
Вы можете использовать GNU gprof, но у него также есть проблема, требующая выхода из программы. Вы можете преодолеть это, вызвав внутренние функции gprof. (см. ниже) Это может быть настоящий "грязный" взлом, в зависимости от версии gcc и, и, и..., но он работает.
#include "sys/gmon.h" extern "C" //the internal functions and vars of gprof { void moncontrol (int mode); void monstartup (unsigned long lowpc, unsigned long highpc); void _mcleanup (void); extern void _start(void), etext(void); extern int __libc_enable_secure; } // call this whenever you want to write profiling information to file void WriteProfilingInformation(char* Name) { setenv("GMON_OUT_PREFIX",Name,1); // set file name int old = __libc_enable_secure; // save old value __libc_enable_secure = 0; // has to be zero to change profile file name _mcleanup(); __libc_enable_secure = old; // reset to old value monstartup(lowpc, highpc); // restart profiler moncontrol(1); // enable profiler }
Rational Purify может это сделать, по крайней мере, на окнах. Кажется, есть версия linux, но я не знаю, может ли она сделать то же самое.
Некоторые инструменты позволяют принудительно анализировать память в любой момент во время выполнения программы. Этот метод не так надежен, как проверка при выходе, но он дает вам отправную точку.
Здесь Пример Windows, используя LeakDiag.
Вы пробовали GNU Gprof?
Обратите внимание, что в этом документе "cc" и "gcc" взаимозаменяемы. ( "cc" считается псевдонимом для "gcc" ). http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html
Ваш вопрос читается так, как будто вы искали top
. Он хорошо отображает (среди прочего) текущее потребление памяти всех запущенных процессов. (Ограничено одной страницей в терминале.) В Linux нажмите "М" для сортировки по использованию памяти. На странице руководства отображаются дополнительные параметры сортировки и фильтрации.
Я использовал рациональный очищающий API для проверки инкрементных утечек. Не использовали API в Linux. Я нашел параметр VALGRIND_DO_LEAK_CHECK в Valgrind User Manual, я думаю, этого было бы достаточно для вашего требования.
Для окон, DebugDiag делает это. В конечном итоге генерирует отчет с вероятными утечками памяти. Также имеет анализ давления памяти. И он доступен для бесплатного @microsoft. Загрузите его из здесь
Вам нужно stackshots. Используйте либо pstack или lsstack, либо просто запустите его в отладчике или в среде IDE и произвольно приостановите его (Ctrl-C). Это не скажет вам об утечке памяти, но это даст вам хорошее представление о том, как используется время и почему.
Если время используется из-за утечек памяти, вы увидите хороший процент образцов, заканчивающихся в подпрограммах управления памятью. Если они находятся в malloc
или new
, выше в стеке вы увидите, какие объекты выделяются и почему, и вы можете подумать, как это сделать реже.
Работа программы, в которой профилирование утечек памяти основано на обнаружении памяти, освобожденной ОС, а не программой.