Из 39 открытых issue большинство — это todo-шки, пожелания и отвеченные вопросы, на которые не хотелось бы отвечать повторно (поэтому не закрываем).
О статусе проекта.
Некоторое время назад проект достиг логического завершения (по функционалу) и в данный момент находится в режиме поддержки. Есть несколько крупных todo-шек, но, к сожалению, особо нет времени ими заниматься :)
Возникающие проблемы решаем по мере возможности (однако, принимая комментарий про время, очень надеемся и на помощь сообщества).
Проект не заброшен, однако, нуждается в активном участии сообщества :)
(Кстати, редактирование Wiki проекта открыто всем желающим!)
По поводу проблемы.
Насчет 10 секунд — временной интервал роли не играет, играет роль количество собранной информации. Возможно, вам стоит попробовать сократить количество профилируемых блоков или временно отключить часть из них (EASY_BLOCK("name", profiler::OFF);) и включать их из UI по мере необходимости.
По поводу диалога — возможно, связано с этой проблемой, предлагаю ознакомиться.
По поводу исключения — возможно оно как раз связано с переполнением памяти, ничего с ходу сказать не могу, нужно больше деталей. Предлагаю перенести дальшейшее обсуждение проблемы на GitHub.
Спасибо :)
Насчет GUI vs core — даже не знаю как оценить что сложнее, и там и там есть свои хитрые особенности.
А вдохновлялись скорее проектом Brofiler :) см. комментарий ниже по тексту.
По поводу профилирования без встраивания в код — пока особо не разбирались в этом вопросе (и в кросс-платформенном варианте здесь, я думаю, все очень непросто), решили начать с простого.
Вы совершенно правы :)
Однако он Windows-only, а нам нужно было профилировать и на Linux. Да, у него есть pull-request с портом под Linux, но он довольно старый и так и не влит. Ну и плюс некоторые вещи для себя более удобно сделали.
Мы, к сожалению, опыта написания плагинов для QtCreator-а не имеем. Если есть желание, можете включиться в разработку и создать плагин. У Вас, скорее всего, это получится лучше, а мы, если потребуется, проконсультируем по особенностям работы профайлера / гуи :)
По 3 пункту: я могу ошибаться, но вроде бы профайлеры, которые собирают информацию "на лету" позволят вам увидеть информацию по приложению в целом, а не по каждому фрейму в отдельности? И это безусловно полезно и во многих случаях большего и не нужно.
Наш профайлер позволит вам увидеть что происходило в каждом конкретном фрейме. Это может быть полезно, если нужно обнаружить причину тормозов в конкретный момент времени.
Для полноты картины я бы использовал оба типа профайлеров.
Цвет задавать не обязательно (так просто нагляднее), а для неймспейсов можно завести более короткие алиасы (на крайний случай using namespace).
Цвета имеют формат uint32_t (ARGB) и использование profiler::colors никому не навызявается — вы можете сформировать свой набор цветов или задавать цвет напрямую (например, 0xff2196f3 вместо profiler::colors::Blue500).
Ну а длинное или короткое имя задать блоку — это ваш выбор.
Если требуется управлять запуском/остановкой сбора профилируемой информации из самого профилируемого приложения, то да, нужно вызывать EASY_PROFILER_ENABLE, EASY_PROFILER_DISABLE.
Другой вариант — управлять запуском/остановкой из GUI. В этом случае, в профилируемом приложении нужно только вызвать profiler::startListen(), а команды старт/стоп будут приходить из GUI.
yPhone :)
Простите за оффтоп
Привет!
Спасибо за интерес к проекту!
Из 39 открытых issue большинство — это todo-шки, пожелания и отвеченные вопросы, на которые не хотелось бы отвечать повторно (поэтому не закрываем).
О статусе проекта.
Некоторое время назад проект достиг логического завершения (по функционалу) и в данный момент находится в режиме поддержки. Есть несколько крупных todo-шек, но, к сожалению, особо нет времени ими заниматься :)
Возникающие проблемы решаем по мере возможности (однако, принимая комментарий про время, очень надеемся и на помощь сообщества).
Проект не заброшен, однако, нуждается в активном участии сообщества :)
(Кстати, редактирование Wiki проекта открыто всем желающим!)
По поводу проблемы.
Насчет 10 секунд — временной интервал роли не играет, играет роль количество собранной информации. Возможно, вам стоит попробовать сократить количество профилируемых блоков или временно отключить часть из них (
EASY_BLOCK("name", profiler::OFF);) и включать их из UI по мере необходимости.По поводу диалога — возможно, связано с этой проблемой, предлагаю ознакомиться.
По поводу исключения — возможно оно как раз связано с переполнением памяти, ничего с ходу сказать не могу, нужно больше деталей. Предлагаю перенести дальшейшее обсуждение проблемы на GitHub.
Насчет GUI vs core — даже не знаю как оценить что сложнее, и там и там есть свои хитрые особенности.
А вдохновлялись скорее проектом Brofiler :) см. комментарий ниже по тексту.
По поводу профилирования без встраивания в код — пока особо не разбирались в этом вопросе (и в кросс-платформенном варианте здесь, я думаю, все очень непросто), решили начать с простого.
Однако он Windows-only, а нам нужно было профилировать и на Linux. Да, у него есть pull-request с портом под Linux, но он довольно старый и так и не влит. Ну и плюс некоторые вещи для себя более удобно сделали.
Да, давненько мы в cmake не заглядывали. Вот так пользуешься старьем, оно работает и не знаешь про такие полезные конструкции :)
Спасибо :)
Вопросы по использованию можете также дублировать мне.
По 3 пункту: я могу ошибаться, но вроде бы профайлеры, которые собирают информацию "на лету" позволят вам увидеть информацию по приложению в целом, а не по каждому фрейму в отдельности? И это безусловно полезно и во многих случаях большего и не нужно.
Наш профайлер позволит вам увидеть что происходило в каждом конкретном фрейме. Это может быть полезно, если нужно обнаружить причину тормозов в конкретный момент времени.
Для полноты картины я бы использовал оба типа профайлеров.
Цвета имеют формат uint32_t (ARGB) и использование profiler::colors никому не навызявается — вы можете сформировать свой набор цветов или задавать цвет напрямую (например, 0xff2196f3 вместо profiler::colors::Blue500).
Ну а длинное или короткое имя задать блоку — это ваш выбор.
Другой вариант — управлять запуском/остановкой из GUI. В этом случае, в профилируемом приложении нужно только вызвать profiler::startListen(), а команды старт/стоп будут приходить из GUI.