2016-05-28 03:34:37 +08:00
|
|
|
|
|
|
|
|
#undef NDEBUG
|
|
|
|
|
#include <utility>
|
|
|
|
|
|
2016-10-08 02:04:50 +08:00
|
|
|
#include "benchmark/benchmark.h"
|
|
|
|
|
#include "output_test.h"
|
2016-05-28 03:34:37 +08:00
|
|
|
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
// ---------------------- Testing Prologue Output -------------------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
2017-03-02 08:23:42 +08:00
|
|
|
ADD_CASES(TC_ConsoleOut,
|
|
|
|
|
{{"^[-]+$", MR_Next},
|
|
|
|
|
{"^Benchmark %s Time %s CPU %s Iterations$", MR_Next},
|
|
|
|
|
{"^[-]+$", MR_Next}});
|
2017-04-28 02:24:06 +08:00
|
|
|
ADD_CASES(TC_CSVOut, {{"%csv_header"}});
|
2016-05-28 03:34:37 +08:00
|
|
|
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
// ------------------------ Testing Basic Output --------------------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_basic(benchmark::State& state) {
|
2016-10-08 02:04:50 +08:00
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
2016-05-28 03:34:37 +08:00
|
|
|
}
|
|
|
|
|
BENCHMARK(BM_basic);
|
|
|
|
|
|
2016-10-08 02:04:50 +08:00
|
|
|
ADD_CASES(TC_ConsoleOut, {{"^BM_basic %console_report$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_basic\",$"},
|
2017-08-01 09:04:02 +08:00
|
|
|
{"\"iterations\": %int,$", MR_Next},
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
{"\"real_time\": %float,$", MR_Next},
|
|
|
|
|
{"\"cpu_time\": %float,$", MR_Next},
|
2016-10-08 02:04:50 +08:00
|
|
|
{"\"time_unit\": \"ns\"$", MR_Next},
|
|
|
|
|
{"}", MR_Next}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_basic\",%csv_report$"}});
|
2016-05-28 03:34:37 +08:00
|
|
|
|
2016-10-29 00:13:57 +08:00
|
|
|
// ========================================================================= //
|
|
|
|
|
// ------------------------ Testing Bytes per Second Output ---------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_bytes_per_second(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
state.SetBytesProcessed(1);
|
|
|
|
|
}
|
|
|
|
|
BENCHMARK(BM_bytes_per_second);
|
|
|
|
|
|
|
|
|
|
ADD_CASES(TC_ConsoleOut,
|
|
|
|
|
{{"^BM_bytes_per_second %console_report +%floatB/s$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_bytes_per_second\",$"},
|
2017-08-01 09:04:02 +08:00
|
|
|
{"\"iterations\": %int,$", MR_Next},
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
{"\"real_time\": %float,$", MR_Next},
|
|
|
|
|
{"\"cpu_time\": %float,$", MR_Next},
|
2016-10-29 00:13:57 +08:00
|
|
|
{"\"time_unit\": \"ns\",$", MR_Next},
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
{"\"bytes_per_second\": %float$", MR_Next},
|
2016-10-29 00:13:57 +08:00
|
|
|
{"}", MR_Next}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_bytes_per_second\",%csv_bytes_report$"}});
|
|
|
|
|
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
// ------------------------ Testing Items per Second Output ---------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_items_per_second(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
state.SetItemsProcessed(1);
|
|
|
|
|
}
|
|
|
|
|
BENCHMARK(BM_items_per_second);
|
|
|
|
|
|
|
|
|
|
ADD_CASES(TC_ConsoleOut,
|
|
|
|
|
{{"^BM_items_per_second %console_report +%float items/s$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_items_per_second\",$"},
|
2017-08-01 09:04:02 +08:00
|
|
|
{"\"iterations\": %int,$", MR_Next},
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
{"\"real_time\": %float,$", MR_Next},
|
|
|
|
|
{"\"cpu_time\": %float,$", MR_Next},
|
2016-10-29 00:13:57 +08:00
|
|
|
{"\"time_unit\": \"ns\",$", MR_Next},
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
{"\"items_per_second\": %float$", MR_Next},
|
2016-10-29 00:13:57 +08:00
|
|
|
{"}", MR_Next}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_items_per_second\",%csv_items_report$"}});
|
|
|
|
|
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
// ------------------------ Testing Label Output --------------------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_label(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
state.SetLabel("some label");
|
|
|
|
|
}
|
|
|
|
|
BENCHMARK(BM_label);
|
|
|
|
|
|
|
|
|
|
ADD_CASES(TC_ConsoleOut, {{"^BM_label %console_report some label$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_label\",$"},
|
2017-08-01 09:04:02 +08:00
|
|
|
{"\"iterations\": %int,$", MR_Next},
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
{"\"real_time\": %float,$", MR_Next},
|
|
|
|
|
{"\"cpu_time\": %float,$", MR_Next},
|
2016-10-29 00:13:57 +08:00
|
|
|
{"\"time_unit\": \"ns\",$", MR_Next},
|
|
|
|
|
{"\"label\": \"some label\"$", MR_Next},
|
|
|
|
|
{"}", MR_Next}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_label\",%csv_label_report_begin\"some "
|
|
|
|
|
"label\"%csv_label_report_end$"}});
|
|
|
|
|
|
2016-05-28 03:34:37 +08:00
|
|
|
// ========================================================================= //
|
|
|
|
|
// ------------------------ Testing Error Output --------------------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_error(benchmark::State& state) {
|
2016-10-08 02:04:50 +08:00
|
|
|
state.SkipWithError("message");
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
2016-05-28 03:34:37 +08:00
|
|
|
}
|
|
|
|
|
BENCHMARK(BM_error);
|
2016-10-08 02:04:50 +08:00
|
|
|
ADD_CASES(TC_ConsoleOut, {{"^BM_error[ ]+ERROR OCCURRED: 'message'$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_error\",$"},
|
|
|
|
|
{"\"error_occurred\": true,$", MR_Next},
|
|
|
|
|
{"\"error_message\": \"message\",$", MR_Next}});
|
2016-05-28 03:34:37 +08:00
|
|
|
|
2016-10-08 02:04:50 +08:00
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_error\",,,,,,,,true,\"message\"$"}});
|
2016-05-28 03:34:37 +08:00
|
|
|
|
2016-10-24 15:49:36 +08:00
|
|
|
// ========================================================================= //
|
|
|
|
|
// ------------------------ Testing No Arg Name Output -----------------------
|
|
|
|
|
// //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_no_arg_name(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
BENCHMARK(BM_no_arg_name)->Arg(3);
|
|
|
|
|
ADD_CASES(TC_ConsoleOut, {{"^BM_no_arg_name/3 %console_report$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_no_arg_name/3\",$"}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_no_arg_name/3\",%csv_report$"}});
|
|
|
|
|
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
// ------------------------ Testing Arg Name Output ----------------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_arg_name(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-10-26 15:36:39 +08:00
|
|
|
BENCHMARK(BM_arg_name)->ArgName("first")->Arg(3);
|
2016-10-24 15:49:36 +08:00
|
|
|
ADD_CASES(TC_ConsoleOut, {{"^BM_arg_name/first:3 %console_report$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_arg_name/first:3\",$"}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_arg_name/first:3\",%csv_report$"}});
|
|
|
|
|
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
// ------------------------ Testing Arg Names Output ----------------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_arg_names(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-10-25 15:45:35 +08:00
|
|
|
BENCHMARK(BM_arg_names)->Args({2, 5, 4})->ArgNames({"first", "", "third"});
|
|
|
|
|
ADD_CASES(TC_ConsoleOut,
|
|
|
|
|
{{"^BM_arg_names/first:2/5/third:4 %console_report$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_arg_names/first:2/5/third:4\",$"}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_arg_names/first:2/5/third:4\",%csv_report$"}});
|
2016-10-24 15:49:36 +08:00
|
|
|
|
2016-05-28 03:34:37 +08:00
|
|
|
// ========================================================================= //
|
|
|
|
|
// ----------------------- Testing Complexity Output ----------------------- //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
void BM_Complexity_O1(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
2016-08-05 03:30:14 +08:00
|
|
|
state.SetComplexityN(state.range(0));
|
2016-05-28 03:34:37 +08:00
|
|
|
}
|
2016-10-08 02:04:50 +08:00
|
|
|
BENCHMARK(BM_Complexity_O1)->Range(1, 1 << 18)->Complexity(benchmark::o1);
|
2016-10-08 11:56:22 +08:00
|
|
|
SET_SUBSTITUTIONS({{"%bigOStr", "[ ]* %float \\([0-9]+\\)"},
|
2016-10-08 02:04:50 +08:00
|
|
|
{"%RMS", "[ ]*[0-9]+ %"}});
|
|
|
|
|
ADD_CASES(TC_ConsoleOut, {{"^BM_Complexity_O1_BigO %bigOStr %bigOStr[ ]*$"},
|
|
|
|
|
{"^BM_Complexity_O1_RMS %RMS %RMS[ ]*$"}});
|
2016-05-28 03:34:37 +08:00
|
|
|
|
2016-08-11 08:20:54 +08:00
|
|
|
// ========================================================================= //
|
|
|
|
|
// ----------------------- Testing Aggregate Output ------------------------ //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
|
|
|
|
// Test that non-aggregate data is printed by default
|
2016-10-08 02:04:50 +08:00
|
|
|
void BM_Repeat(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-11 08:20:54 +08:00
|
|
|
BENCHMARK(BM_Repeat)->Repetitions(3);
|
2016-10-08 02:04:50 +08:00
|
|
|
ADD_CASES(TC_ConsoleOut, {{"^BM_Repeat/repeats:3 %console_report$"},
|
|
|
|
|
{"^BM_Repeat/repeats:3 %console_report$"},
|
|
|
|
|
{"^BM_Repeat/repeats:3 %console_report$"},
|
|
|
|
|
{"^BM_Repeat/repeats:3_mean %console_report$"},
|
|
|
|
|
{"^BM_Repeat/repeats:3_stddev %console_report$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_Repeat/repeats:3\",$"},
|
|
|
|
|
{"\"name\": \"BM_Repeat/repeats:3\",$"},
|
|
|
|
|
{"\"name\": \"BM_Repeat/repeats:3\",$"},
|
|
|
|
|
{"\"name\": \"BM_Repeat/repeats:3_mean\",$"},
|
|
|
|
|
{"\"name\": \"BM_Repeat/repeats:3_stddev\",$"}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_Repeat/repeats:3\",%csv_report$"},
|
|
|
|
|
{"^\"BM_Repeat/repeats:3\",%csv_report$"},
|
|
|
|
|
{"^\"BM_Repeat/repeats:3\",%csv_report$"},
|
|
|
|
|
{"^\"BM_Repeat/repeats:3_mean\",%csv_report$"},
|
|
|
|
|
{"^\"BM_Repeat/repeats:3_stddev\",%csv_report$"}});
|
2016-08-11 08:20:54 +08:00
|
|
|
|
|
|
|
|
// Test that a non-repeated test still prints non-aggregate results even when
|
|
|
|
|
// only-aggregate reports have been requested
|
2016-10-08 02:04:50 +08:00
|
|
|
void BM_RepeatOnce(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-11 08:20:54 +08:00
|
|
|
BENCHMARK(BM_RepeatOnce)->Repetitions(1)->ReportAggregatesOnly();
|
2016-10-08 02:04:50 +08:00
|
|
|
ADD_CASES(TC_ConsoleOut, {{"^BM_RepeatOnce/repeats:1 %console_report$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{"\"name\": \"BM_RepeatOnce/repeats:1\",$"}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{"^\"BM_RepeatOnce/repeats:1\",%csv_report$"}});
|
2016-08-29 03:24:16 +08:00
|
|
|
|
2016-08-11 08:20:54 +08:00
|
|
|
// Test that non-aggregate data is not reported
|
2016-10-08 02:04:50 +08:00
|
|
|
void BM_SummaryRepeat(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-11 08:20:54 +08:00
|
|
|
BENCHMARK(BM_SummaryRepeat)->Repetitions(3)->ReportAggregatesOnly();
|
2016-10-08 02:04:50 +08:00
|
|
|
ADD_CASES(TC_ConsoleOut,
|
|
|
|
|
{{".*BM_SummaryRepeat/repeats:3 ", MR_Not},
|
|
|
|
|
{"^BM_SummaryRepeat/repeats:3_mean %console_report$"},
|
|
|
|
|
{"^BM_SummaryRepeat/repeats:3_stddev %console_report$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{".*BM_SummaryRepeat/repeats:3 ", MR_Not},
|
|
|
|
|
{"\"name\": \"BM_SummaryRepeat/repeats:3_mean\",$"},
|
|
|
|
|
{"\"name\": \"BM_SummaryRepeat/repeats:3_stddev\",$"}});
|
|
|
|
|
ADD_CASES(TC_CSVOut, {{".*BM_SummaryRepeat/repeats:3 ", MR_Not},
|
|
|
|
|
{"^\"BM_SummaryRepeat/repeats:3_mean\",%csv_report$"},
|
|
|
|
|
{"^\"BM_SummaryRepeat/repeats:3_stddev\",%csv_report$"}});
|
2016-08-11 08:20:54 +08:00
|
|
|
|
2016-10-21 20:59:06 +08:00
|
|
|
void BM_RepeatTimeUnit(benchmark::State& state) {
|
|
|
|
|
while (state.KeepRunning()) {
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
BENCHMARK(BM_RepeatTimeUnit)
|
|
|
|
|
->Repetitions(3)
|
|
|
|
|
->ReportAggregatesOnly()
|
|
|
|
|
->Unit(benchmark::kMicrosecond);
|
|
|
|
|
ADD_CASES(TC_ConsoleOut,
|
|
|
|
|
{{".*BM_RepeatTimeUnit/repeats:3 ", MR_Not},
|
|
|
|
|
{"^BM_RepeatTimeUnit/repeats:3_mean %console_us_report$"},
|
|
|
|
|
{"^BM_RepeatTimeUnit/repeats:3_stddev %console_us_report$"}});
|
|
|
|
|
ADD_CASES(TC_JSONOut, {{".*BM_RepeatTimeUnit/repeats:3 ", MR_Not},
|
|
|
|
|
{"\"name\": \"BM_RepeatTimeUnit/repeats:3_mean\",$"},
|
|
|
|
|
{"\"time_unit\": \"us\",?$"},
|
|
|
|
|
{"\"name\": \"BM_RepeatTimeUnit/repeats:3_stddev\",$"},
|
|
|
|
|
{"\"time_unit\": \"us\",?$"}});
|
|
|
|
|
ADD_CASES(TC_CSVOut,
|
|
|
|
|
{{".*BM_RepeatTimeUnit/repeats:3 ", MR_Not},
|
|
|
|
|
{"^\"BM_RepeatTimeUnit/repeats:3_mean\",%csv_us_report$"},
|
|
|
|
|
{"^\"BM_RepeatTimeUnit/repeats:3_stddev\",%csv_us_report$"}});
|
|
|
|
|
|
2016-05-28 03:34:37 +08:00
|
|
|
// ========================================================================= //
|
|
|
|
|
// --------------------------- TEST CASES END ------------------------------ //
|
|
|
|
|
// ========================================================================= //
|
|
|
|
|
|
2016-10-21 20:59:06 +08:00
|
|
|
int main(int argc, char* argv[]) { RunOutputTests(argc, argv); }
|
