unit-tests & benchmark
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 04.10.18 10:49
Оценка:
Понадобилось прикрутить замеры скорости к нашим тестам и возник вопрос, что сейчас популярно в этой области, Я раньше использовал hayai и был вполне доволен, но может что-то лучше появилось?

В идеале я бы хотел эта библиотека:

  1. была интегрирована c GTest;
  2. как-то интегрирована с Jenkins.
Re: unit-tests & benchmark
От: koenjihyakkei Россия  
Дата: 04.10.18 11:29
Оценка:
Здравствуйте, kaa.python, Вы писали:

А можно не ответ, а вопрос Зависят ли результаты работы этого hayai от загруженности машины? То есть если его запустить на машине, у которой загрузка 100%, увеличатся ли результаты замера скорости?
Re[2]: unit-tests & benchmark
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 04.10.18 11:34
Оценка:
Здравствуйте, koenjihyakkei, Вы писали:

K>А можно не ответ, а вопрос Зависят ли результаты работы этого hayai от загруженности машины? То есть если его запустить на машине, у которой загрузка 100%, увеличатся ли результаты замера скорости?


Да, изменятся конечно. Но в случае интеграции такой штуки в пайплайн, подобные отклонения не имеют особого значения, так как важное направление, а не текущее значение как таковое.
Re: unit-tests & benchmark
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 04.10.18 11:56
Оценка:
Здравствуйте, kaa.python, Вы писали:

Хотя я вроде плохо искал, как минимум есть https://github.com/google/benchmark, который вроде и делает то, что мне нужно
Re: unit-tests & benchmark
От: Vain Россия google.ru
Дата: 24.11.18 16:30
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Понадобилось прикрутить замеры скорости к нашим тестам и возник вопрос, что сейчас популярно в этой области, Я раньше использовал hayai и был вполне доволен, но может что-то лучше появилось?

KP>В идеале я бы хотел эта библиотека:
KP>была интегрирована c GTest;
У меня обычный макрос с супрессией оптимизации на переменной и запуск gtest из релиза, он сам уже умеет мерять время, а точность добивается просто увеличенным количеством итераций.
  UTILITY_SUPPRESS_OPTIMIZATION_ON_VAR
.hpp
#define UTILITY_SUPPRESS_OPTIMIZATION_ON_VAR(var)   ::utility::unused_param(&var)

namespace utility {

    extern const volatile void * volatile g_unused_param_storage_ptr;

    extern void
#ifdef __GNUC__
    __attribute__((optimize("O0")))
#endif
        unused_param(const volatile void * p);

}

.cpp
namespace utility {

    const volatile void * volatile g_unused_param_storage_ptr = nullptr;

    void
#ifdef __GNUC__
    __attribute__((optimize("O0")))
#endif
        unused_param(const volatile void * p)
    {
        g_unused_param_storage_ptr = p;
    }

}

example.cpp
TEST(TestBlabla, test_blabla_x100)
{
    for (size_t i = 0; i < 100; i++) {
        auto res = ...;
        UTILITY_SUPPRESS_OPTIMIZATION_ON_VAR(res);
    }
}

KP>как-то интегрирована с Jenkins.
Как то ковырял я этот дженкинс, года этак 2-3 назад, ещё то поделие, при увеличении плагинов до критической массы — жрёт память из-за ликов (ага, в джаве), начинает тормозить и потом падает из-за нехватки памяти. Приходилось постоянно перезапускать весь сервер.
С билдботом вообще таких проблем нет ибо всё из коробки и отлажено как единое целое.
Но даже без такого варианта, не понятно, зачем там надо что-то интегрировать со стороны CI.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.