github.com/coocood/badger@v1.5.1-0.20200528065104-c02ac3616d04/table/sstable/README.md (about)

     1  # BenchmarkRead
     2  
     3  ```
     4  $ go test -bench Read$ -count 3
     5  
     6  Size of table: 105843444
     7  BenchmarkRead-8   	3	 343846914 ns/op
     8  BenchmarkRead-8   	3	 351790907 ns/op
     9  BenchmarkRead-8   	3	 351762823 ns/op
    10  ```
    11  
    12  Size of table is 105,843,444 bytes, which is ~101M.
    13  
    14  The rate is ~287M/s which matches our read speed. This is using mmap.
    15  
    16  To read a 64M table, this would take ~0.22s, which is negligible.
    17  
    18  ```
    19  $ go test -bench BenchmarkReadAndBuild -count 3
    20  
    21  BenchmarkReadAndBuild-8   	       1	2341034225 ns/op
    22  BenchmarkReadAndBuild-8   	       1	2346349671 ns/op
    23  BenchmarkReadAndBuild-8   	       1	2364064576 ns/op
    24  ```
    25  
    26  The rate is ~43M/s. To build a ~64M table, this would take ~1.5s. Note that this
    27  does NOT include the flushing of the table to disk. All we are doing above is
    28  to read one table (mmaped) and write one table in memory.
    29  
    30  The table building takes 1.5-0.22 ~ 1.3s.
    31  
    32  If we are writing out up to 10 tables, this would take 1.5*10 ~ 15s, and ~13s
    33  is spent building the tables.
    34  
    35  When running populate, building one table in memory tends to take ~1.5s to ~2.5s
    36  on my system. Where does this overhead come from? Let's investigate the merging.
    37  
    38  Below, we merge 5 tables. The total size remains unchanged at ~101M.
    39  
    40  ```
    41  $ go test -bench ReadMerged -count 3
    42  BenchmarkReadMerged-8   	       1	1321190264 ns/op
    43  BenchmarkReadMerged-8   	       1	1296958737 ns/op
    44  BenchmarkReadMerged-8   	       1	1314381178 ns/op
    45  ```
    46  
    47  The rate is ~76M/s. To build a 64M table, this would take ~0.84s. The writing
    48  takes ~1.3s as we saw above. So in total, we expect around 0.84+1.3 ~ 2.1s.
    49  This roughly matches what we observe when running populate. There might be
    50  some additional overhead due to the concurrent writes going on, in flushing the
    51  table to disk. Also, the tables tend to be slightly bigger than 64M/s.