commit | 9fd9e418858c3414eabbeb5031fa193579575555 | [log] [tgz] |
---|---|---|
author | Lalit Maganti <lalitm@google.com> | Thu Sep 26 11:27:21 2019 +0100 |
committer | Lalit Maganti <lalitm@google.com> | Thu Sep 26 11:27:21 2019 +0100 |
tree | 9a59bcf299ec127924b1f92ea96f42c147379da5 | |
parent | 53fa633591c3418823b82d844f22e3ad9abd7e97 [diff] |
trace_processor: break Append -> Append{True,False} and Set -> Set,Clear This CL changes the Append and Set methods of bitvector to stop taking a bool parameter but instead have explicit methods for the true and false variant. There are a few reasons for doing this: 1. In most real world usage of bitvector, we will actually be passing a constant so having separate methods allows the compiler to better inline and optimize 2. Even if the vector<bool> implementation looks like it would write the bit to the storage, it's actually far more efficient to have both methods according to the benchmarks (see below) 3. In the upcoming refactor of bitvector, having the separate methods is an order of magnitude more efficient and changing this in the old code allows for more accurate benchmark comparisions. Old numbers: ----------------------------------------------------------------- Benchmark Time CPU Iterations ----------------------------------------------------------------- BM_BitVectorAppend 6 ns 6 ns 118772108 BM_BitVectorSet 5 ns 5 ns 145386020 BM_BitVectorIndexOfNthSet 173538 ns 173538 ns 4010 BM_BitVectorGetNumBitsSet 2930 ns 2930 ns 240818 New numbers: ----------------------------------------------------------------- Benchmark Time CPU Iterations ----------------------------------------------------------------- BM_BitVectorAppendTrue 2 ns 2 ns 352256359 BM_BitVectorAppendFalse 2 ns 2 ns 352757342 BM_BitVectorSet 1 ns 1 ns 553163208 BM_BitVectorClear 1 ns 1 ns 536258728 BM_BitVectorIndexOfNthSet 171802 ns 171775 ns 4010 BM_BitVectorGetNumBitsSet 2904 ns 2903 ns 229680 Analysis: As we can see, having separate append methods cuts timings from 6ns -> 2 ns and separate Set/Clear cuts from 5ns -> 1ns! Context: go/perfetto-tp-refactor Bug: 135177627 Change-Id: Iec3bf9b8633391b10e29b97124db90b602f2d9f6
Perfetto is an open-source project for performance instrumentation and tracing of Linux/Android/Chrome platforms and user-space apps.
See www.perfetto.dev for docs.