google / benchmark / 1291 / 1

92%

master: 92%

Pull #507

travis-ci

<a href="https://github.com/google/benchmark/commit/<a class=hub.com/google/benchmark/commit/196d87a4c706a6311faf2eb55ea286d083094e8e">196d87a4c<a href="https://github.com/google/benchmark/commit/196d87a4c706a6311faf2eb55ea286d083094e8e">&quot;&gt;Use int64_t instead of size_t for items/bytes/iterations

</a><a class="double-link" href="https://github.com/google/benchmark/commit/<a class="double-link" href="https://github.com/google/benchmark/commit/7a767012f1c423b37069f6d315b97164b5850271">7a767012f</a>">7a767012f</a><a href="https://github.com/google/benchmark/commit/196d87a4c706a6311faf2eb55ea286d083094e8e"> seemingly unintentionally changed the data types
for bytes_processed, items_processed, and iterations to size_t. On 32-bit systems, the
bytes_processed and items_processed variables easily overflow, and often report fewer
items/second for faster code. The fact that overflow chances depends on architecture
and even ABI (e.g. x64 vsi x32 ABI on x86-64) makes it particularly annoying.
iterations counter is made to use int32_t internally because it is incremented in the hot
loop, and incrementing int64_t is slow on some 32-bit platforms (e.g. Asm.js). However,
the public interface State.iterations() is changed to return int64_t.

1476 of 1698 relevant lines covered (86.93%)

4666028.36 hits per line