Комментарии 42
Другой вариант — управлять запуском/остановкой из GUI. В этом случае, в профилируемом приложении нужно только вызвать profiler::startListen(), а команды старт/стоп будут приходить из GUI.
EASY_BLOCK("Calculating multiplication", profiler::colors::Blue500);Ох длиннющая же запись. Предеться обкладывать дефайнами или инлайнами. Пишешь код в 30 символов, а профайлер в 130.
Цвета имеют формат uint32_t (ARGB) и использование profiler::colors никому не навызявается — вы можете сформировать свой набор цветов или задавать цвет напрямую (например, 0xff2196f3 вместо profiler::colors::Blue500).
Ну а длинное или короткое имя задать блоку — это ваш выбор.
Я, конечно, собирать не пробовал, но в описании только lib/win. Мака нет.
2. Что с лицензией? Что под апаче, что под gpl?
3. Минусы: требует правки кода, умеет только именованные участки, не умеет показывать узкие места ( в отличии от perf, xcode и того, что там в студии)
Мака нет.
К сожалению под рукой мака нет, но clang`ом вроде собирается, используется Qt. Так что судя по всему под маком тоже взлетит без проблем. Если есть у кого собрать и проверить под маком — будем рады
Что с лицензией?
Используйте либо апач, либо GPL. И gui и либина под этими лицензиями. Обновлю информацию сразу в статью. Спасибо!
Минусы: требует правки кода...
Я бы не стал говорить, что это прям минус, неудобно, да, но практика показывает, что иногда наоборот кусочно полезно профилировать.
По 3 пункту: я могу ошибаться, но вроде бы профайлеры, которые собирают информацию "на лету" позволят вам увидеть информацию по приложению в целом, а не по каждому фрейму в отдельности? И это безусловно полезно и во многих случаях большего и не нужно.
Наш профайлер позволит вам увидеть что происходило в каждом конкретном фрейме. Это может быть полезно, если нужно обнаружить причину тормозов в конкретный момент времени.
Для полноты картины я бы использовал оба типа профайлеров.
Для полноты картины я бы использовал оба типа профайлеров.
У нас как раз такая практика — "настоящим" профайлером ищем узкие места, а потом обкладываем их в коде замерами, подобными сабжевым, и вперед оптимизировать.
Получаем преимущества обоих методов
- точная локализация узких мест инструментальным профилированием (xcode, vtune, etc)
- быстрые и повторяемые замеры ручным профилированием во время решения найденных проблем
XCode Instruments ИМХО вполне сравним с V-Tune'ом, бесплатно, без SMS
XCode Instruments умеет считать HW счетчики производительности.
Можно выбрать из большого списка, что интересует, например кэш промахи по данным L1.
Правда кол-во одновременно наблюдаемых счетчиков ограничено, но я думаю это ограничение конкретного CPU.
Правда на ARM, к сожалению, performance counters не доступны, но с другой стороны v-tune эту архитектуру вообще не поддерживает.
XCode Instruments не зависит от исходного кода, ему нужен бинарник и файл с символами.
Были идеи плагина, который позволял бы автоматически блоки проставлять в функции, отображал бы цвет блоков, в общем плагин для кода. А вот гуи добавить что-то мыслей не возникло =( Спасибо за подсказку!
Во-вторых, хочется все это проинсталлировать в систему (Linux), а не собирать все это в отдельную папку, потом прописать пути и т.д. Инсталляции пока нет.
В-третьих, раз уж используется cmake, хочется в своем проекте просто написать find_package(easy_profiler) и получить сразу пути к хедерам и библиотекам, а также все необходимые дефайны. А чтобы руками не писать модуль FindEasyProfiler.cmake, рекомендую почитать про package layout cmake. То есть это позволит проинсталлировать в систему вашу библиотеку сразу с автоматически сгенерированным конфигом cmake со всеми правильными путями, клиенту нужно будет написать в своем коде только find_package(easy_profiler).
Есть еще вопросы конкретно по использованию, но я их в личку напишу.
Молодцы, хороший прибор сделали. Насколько я понимаю, GUI часть намного сложнее чем сборщик :)
Вдохновение пришло, наверное, от Event Tracing for Windows API + GPUView.
Есть ещё аналогичный подход у Гугла — systrace (https://developer.android.com/studio/profile/systrace.html)
Intel PCM, про который тут упоминали, просто меряет hardware performace counters без привязки к коду. Это совсем другой подход. Раз уж тут упомянули Vtune и CodeXL, то было бы очень круто сделать из вашего профилировщика плагин для CodeXL. Ещё крутой фичей было бы профилирование чужого кода (то есть без возможности перекомпиляции), например замерять время вызова некоторых функций или участков кода. Это можно сделать с помощью инструментирования бинарного кода (см. pintool).
Я с вами согласен в том, что часто бывает проще сделать свой прибор на известной технологии, чем изучать чужие приборы и подходы и адаптировать их под свои проекты.
Насчет GUI vs core — даже не знаю как оценить что сложнее, и там и там есть свои хитрые особенности.
А вдохновлялись скорее проектом Brofiler :) см. комментарий ниже по тексту.
По поводу профилирования без встраивания в код — пока особо не разбирались в этом вопросе (и в кросс-платформенном варианте здесь, я думаю, все очень непросто), решили начать с простого.
Отдельное спасибо oYASo за совет об автоматической генерации файлов cmake (посредством package layout cmake). Пользователям данной системы сборки теперь достаточно писать
find_package(easy_profiler). Это действительно удобно. Обновил информацию в статье.Дело в том, что в коде сборки вы переопределяете CMAKE_INSTALL_PREFIX на папку в директории с сорцами sdk. Если ее оставить пустой, то по умолчанию на никсах она определена как /usr/local. Вам остается просто написать, что инсталлировать хедеры нужно в include/easy_profiler, либки в lib/, исполняемые файлы в bin/, файлы со скриптами можно кинуть в share/. А фишка в том, что cmake по умолчанию ищет свои конфигурационные файлы в /usr/local/lib/cmake. Это значит, что если вы просто на никсах будете устанавливать все в папки по умолчанию, то прям из коробки можно будет писать
cmake…
make
sudo make install
и дальше в коде, без CMAKE_PREFIX_PATH, сразу писать
find_package(easy_profiler).
На винде, увы, это не прокатит, потому что там нет логики рассовывания библиотек по системе, поэтому CMAKE_PREFIX_PATH писать придется.
Далее, есть еще такое предложение. Везде в коде вы пишите add_definitions и include_directories. На самом деле, это штука устаревшая, и работает локально. Намного удобнее использовать target_compile_definitions и target_include_directories, которым можно указывать дополнительно PUBLIC, PRIVATE, INTERFACE в зависимости от того, нужно ли экспортировать эти директивы и хедеры в проекты, которые подключают ваш проект. В итоге, если вы определите target_compile_definitions(easy_profiler PUBLIC BUILD_WITH_EASY_PROFILER), то все проекты, которые будут указывать в target_link_libraries вашу библиотеку, автоматически подключает все определения с модификатором PUBLIC. Тоже самое касается и хедеров, если проделать аналогичное с target_include_directories.
Ваш проект как раз то, что мне требуется, однако… Вы его забросили? 39 активных проблем на гитхабе, у меня в примитивном случае показывает какую-то статистику, чуть углубился — ничего не показывает, молча закрывается диалог Receiving Data.... Если подержать побольше сбор статистики (больше 10 секунд), валится по Необработанное исключение по адресу 0x68B426EE (easy_profiler.dll) в *.exe: 0xC0000005: нарушение прав доступа при записи по адресу 0x00000B80.
Или проект будет жить?
Привет!
Спасибо за интерес к проекту!
Из 39 открытых issue большинство — это todo-шки, пожелания и отвеченные вопросы, на которые не хотелось бы отвечать повторно (поэтому не закрываем).
О статусе проекта.
Некоторое время назад проект достиг логического завершения (по функционалу) и в данный момент находится в режиме поддержки. Есть несколько крупных todo-шек, но, к сожалению, особо нет времени ими заниматься :)
Возникающие проблемы решаем по мере возможности (однако, принимая комментарий про время, очень надеемся и на помощь сообщества).
Проект не заброшен, однако, нуждается в активном участии сообщества :)
(Кстати, редактирование Wiki проекта открыто всем желающим!)
По поводу проблемы.
Насчет 10 секунд — временной интервал роли не играет, играет роль количество собранной информации. Возможно, вам стоит попробовать сократить количество профилируемых блоков или временно отключить часть из них (EASY_BLOCK("name", profiler::OFF);) и включать их из UI по мере необходимости.
По поводу диалога — возможно, связано с этой проблемой, предлагаю ознакомиться.
По поводу исключения — возможно оно как раз связано с переполнением памяти, ничего с ходу сказать не могу, нужно больше деталей. Предлагаю перенести дальшейшее обсуждение проблемы на GitHub.
Да, проект вполне себе живёт и будет жить! Просто не так активно развивается, как прежде. Если что-то где-то падает при сборе — отрывайте баг на гитхабе. Баги приоритетнее, чем новый функционал. Стараемся решать возникающие проблемы. Зачастую возникающие ошибки — это следствие самой крупной баги — нехватки детальной документации по интеграции =)
Шустрый, удобный и кроссплатформенный профилировщик C++ кода