Как стать автором
Обновить

Комментарии 42

Как то сумбурно изложено, как инициализировать профайлер в начале, я так понимаю вызовом EASY_PROFILER_ENABLE;?
Это макрос сразу начинает сессию профилирования. Это удобно для сохранения в дальнейшем в файл. Если подключаться через gui-приложение, то данный макрос необязателен
Если требуется управлять запуском/остановкой сбора профилируемой информации из самого профилируемого приложения, то да, нужно вызывать EASY_PROFILER_ENABLE, EASY_PROFILER_DISABLE.
Другой вариант — управлять запуском/остановкой из GUI. В этом случае, в профилируемом приложении нужно только вызвать profiler::startListen(), а команды старт/стоп будут приходить из GUI.
Возможно ли рисовать в риалтайме графики профилирования, как, например, это сделано в профилировщике Visual Studio? В GUI.
Сами графики в реалтайме не идут. Но это можно предусмотреть на будущее. По опыту решения наших задач вполне достаточно профилировать сессиями.
EASY_BLOCK("Calculating multiplication", profiler::colors::Blue500);

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

Цвет задавать не обязательно (так просто нагляднее), а для неймспейсов можно завести более короткие алиасы (на крайний случай using namespace).
Цвета имеют формат uint32_t (ARGB) и использование profiler::colors никому не навызявается — вы можете сформировать свой набор цветов или задавать цвет напрямую (например, 0xff2196f3 вместо profiler::colors::Blue500).
Ну а длинное или короткое имя задать блоку — это ваш выбор.
1. >Кроссплатформенный
Я, конечно, собирать не пробовал, но в описании только lib/win. Мака нет.
2. Что с лицензией? Что под апаче, что под gpl?
3. Минусы: требует правки кода, умеет только именованные участки, не умеет показывать узкие места ( в отличии от perf, xcode и того, что там в студии)
Мака нет.

К сожалению под рукой мака нет, но clang`ом вроде собирается, используется Qt. Так что судя по всему под маком тоже взлетит без проблем. Если есть у кого собрать и проверить под маком — будем рады
Что с лицензией?

Используйте либо апач, либо GPL. И gui и либина под этими лицензиями. Обновлю информацию сразу в статью. Спасибо!
Минусы: требует правки кода...

Я бы не стал говорить, что это прям минус, неудобно, да, но практика показывает, что иногда наоборот кусочно полезно профилировать.
Мне кажется, что на Mac/FreeBSD/Solaris лучше использовать DTrace
У мака гуевина в xcode удобная, afaik там dtrace под капотом.

По 3 пункту: я могу ошибаться, но вроде бы профайлеры, которые собирают информацию "на лету" позволят вам увидеть информацию по приложению в целом, а не по каждому фрейму в отдельности? И это безусловно полезно и во многих случаях большего и не нужно.
Наш профайлер позволит вам увидеть что происходило в каждом конкретном фрейме. Это может быть полезно, если нужно обнаружить причину тормозов в конкретный момент времени.
Для полноты картины я бы использовал оба типа профайлеров.

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

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


  • точная локализация узких мест инструментальным профилированием (xcode, vtune, etc)
  • быстрые и повторяемые замеры ручным профилированием во время решения найденных проблем
Лучший из известных мне профилировщиков — Intel VTune. Профилировщик от AMD (CodeAnalyst) уже значительно хуже, зато бесплатный. Оба они работают и в Windows, и в Linux. Все остальные известные мне профилировщики по возможностям вообще не сравнимы с этими двумя.

XCode Instruments ИМХО вполне сравним с V-Tune'ом, бесплатно, без SMS

А самое главное — VTune один из немногих использует хардварные возможности. У интеля есть либа с исходниками на гитхабе, дающая доступ к этим хардварным перформанс счетчикам, это самый точный способ на интеле. По идее эти хардварные каунтеры можно прикрутить и к этому профилировщику, добавить sampling профайл и не надо будет менять код вообще, нужна только отладочная инфа. Только под виндой ему нужен драйвер для доступа к MSR регистрам, потому в винде в том числе и VTune иногда ломается, в лине работает из коробки без драйвера.

XCode Instruments умеет считать HW счетчики производительности.
Можно выбрать из большого списка, что интересует, например кэш промахи по данным L1.
Правда кол-во одновременно наблюдаемых счетчиков ограничено, но я думаю это ограничение конкретного CPU.
Правда на ARM, к сожалению, performance counters не доступны, но с другой стороны v-tune эту архитектуру вообще не поддерживает.


XCode Instruments не зависит от исходного кода, ему нужен бинарник и файл с символами.

Да, XCode тоже поддерживает, в либе поддержка macos кстати тоже есть, и тоже нужен MacMSRDriver.
Так что теоретически можно сделать аля кроссплатформенный VTune отпенсорсный.
НЛО прилетело и опубликовало эту надпись здесь
Я про либу с гитхаба, как и perf отдельные модули ядра им не нужны, все уже есть в ядре давным давно (конфиг CONFIG_HW_PERF_EVENTS, отключенным его не видел). Ими можно пользоваться и вообще без софта из скриптов через /sys/, но не все возможности, а так же в своей программе через libperf.
Раз уж на Qt, как насчёт плагина для QtCreator-а? :)
Вы имеете в виду gui проинтегрировать в QtCreator? Любопытная мысль, что инструмент под рукой.
Были идеи плагина, который позволял бы автоматически блоки проставлять в функции, отображал бы цвет блоков, в общем плагин для кода. А вот гуи добавить что-то мыслей не возникло =( Спасибо за подсказку!

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

Мы, к сожалению, опыта написания плагинов для QtCreator-а не имеем. Если есть желание, можете включиться в разработку и создать плагин. У Вас, скорее всего, это получится лучше, а мы, если потребуется, проконсультируем по особенностям работы профайлера / гуи :)
Выглядит клево! Попробуем, спасибо!
Спасибо! Ждём обратной связи! =)
О чем хочется сразу сказать — поправьте нормально файлы сборки. Дело в том, что, во-первых, при указании cmake папки сборки, финальные исполняемые файлы все равно зачем-то копируются в каталог сорцов. Портить папку с сорцами, особенно когда я указал этого не делать — плохой тон.
Во-вторых, хочется все это проинсталлировать в систему (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.

Да, давненько мы в cmake не заглядывали. Вот так пользуешься старьем, оно работает и не знаешь про такие полезные конструкции :)
Спасибо :)

Странно, что ещё никто не упомянул brofiler. Вы случайно не им вдохновлялись?
Вы совершенно правы :)
Однако он Windows-only, а нам нужно было профилировать и на Linux. Да, у него есть pull-request с портом под Linux, но он довольно старый и так и не влит. Ну и плюс некоторые вещи для себя более удобно сделали.
Мда… Проект то интересный, но попробовать не удалось))) использую Windows + Qt 5.7.0 + mingw 5.3.0 — итог: при компиляции куча ошибок…
Не могли бы Вы прислать лог ошибок мне в приват?

Ваш проект как раз то, что мне требуется, однако… Вы его забросили? 39 активных проблем на гитхабе, у меня в примитивном случае показывает какую-то статистику, чуть углубился — ничего не показывает, молча закрывается диалог Receiving Data.... Если подержать побольше сбор статистики (больше 10 секунд), валится по Необработанное исключение по адресу 0x68B426EE (easy_profiler.dll) в *.exe: 0xC0000005: нарушение прав доступа при записи по адресу 0x00000B80.


Или проект будет жить?

Привет!
Спасибо за интерес к проекту!


Из 39 открытых issue большинство — это todo-шки, пожелания и отвеченные вопросы, на которые не хотелось бы отвечать повторно (поэтому не закрываем).


О статусе проекта.
Некоторое время назад проект достиг логического завершения (по функционалу) и в данный момент находится в режиме поддержки. Есть несколько крупных todo-шек, но, к сожалению, особо нет времени ими заниматься :)
Возникающие проблемы решаем по мере возможности (однако, принимая комментарий про время, очень надеемся и на помощь сообщества).
Проект не заброшен, однако, нуждается в активном участии сообщества :)
(Кстати, редактирование Wiki проекта открыто всем желающим!)


По поводу проблемы.
Насчет 10 секунд — временной интервал роли не играет, играет роль количество собранной информации. Возможно, вам стоит попробовать сократить количество профилируемых блоков или временно отключить часть из них (EASY_BLOCK("name", profiler::OFF);) и включать их из UI по мере необходимости.
По поводу диалога — возможно, связано с этой проблемой, предлагаю ознакомиться.
По поводу исключения — возможно оно как раз связано с переполнением памяти, ничего с ходу сказать не могу, нужно больше деталей. Предлагаю перенести дальшейшее обсуждение проблемы на GitHub.

Привет!
Да, проект вполне себе живёт и будет жить! Просто не так активно развивается, как прежде. Если что-то где-то падает при сборе — отрывайте баг на гитхабе. Баги приоритетнее, чем новый функционал. Стараемся решать возникающие проблемы. Зачастую возникающие ошибки — это следствие самой крупной баги — нехватки детальной документации по интеграции =)
Ok, соберу его из исходников, запущу в отладке и посмотрю, из-за чего падает. Сейчас даже и написать-то конкретики нет. До встречи на гитхабе)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории