原子变量导致 Pika 性能下降 90%

[AlexStocks]

PR #2622 改进了 Pika 加载配置的方式，加载配置时从使用锁改为使用 min_write_buffer_number_to_merge_.load(std::memory_order_relaxed) 原子形式的变量。

上面这个 PR 合进去以后，Pika的写速度大幅下降：

这个PR之前：valueSize=1KB，写ops能到24W，valueSize=10KB, 写Ops能到9.6W
这个PR之后：valueSize=1KB，写ops只到4.2W，valueSize=10KB, 写Ops只到0.6W

原因：

1 把一些读锁改为了原子变量访问，通过 perf 发现 cache miss 会翻一倍。
2 他这个pr不止是去掉了锁，原来一些没有锁的配置项（一些配置项，在pika启动时赋值，后面不会再修改，只会高并发的读），他也给搞成原子变量了

比如说这些判断当前请求是否要走cache配置项，每一条请求都会去读取，并发量极高，本来人家就是普通类型，也无锁。他加上原子变量了，搞的就有竞争了。

最终：

在 #2636 这个 PR 中，revert 了 PR #2622 。

[QlQlqiqi]

比如说这些判断当前请求是否要走 cache 配置项，每一条请求都会去读取，并发量极高，本来人家就是普通类型，也无锁
我觉得差不多这个意思：比如：

1. 以 small_compaction_threshold_ 为例子：在 pika_conf.h 中，本来 small_compaction_threshold_ 是 int，通过在 small_compaction_threshold() 中加锁实现原子读、在 SetSmallCompactionThreshold 实现原子写，如果这两个函数调用占比过大，那么修改锁为原子性一点问题没有。但是，如果占比过小，那么这样修改类似舍本逐末。本身其他地方读都是 int 读，修改为 std::atomic<int> 是很慢的。
2. 在 base_conf.h 中，原来的 bool GetConfIntHuman(const std::string& name, int* value) const; 函数是非模板的，但是后面改成了
   template<typename T> bool GetConfIntHuman(const std::string& name, T* value) const，是模板的，但是调用似乎只有 std::atomic，且 value 在函数内部实现并没有发挥 std::atomic<int> 应有的作用，如：

template<typename T>
  bool GetConfIntHuman(const std::string& name, T* value) const {
    for (auto& i : rep_->item) {
      if (i.type == Rep::kComment) {
        continue;
      }
      if (name == i.name) {
        auto c_str = i.value.c_str();
        (*value) = static_cast<int32_t>(strtoll(c_str, nullptr, 10));
        char last = c_str[i.value.size() - 1];
        if (last == 'K' || last == 'k') {
          (*value) = (*value) * (1 << 10);
        } else if (last == 'M' || last == 'm') {
          (*value) = (*value) * (1 << 20);
        } else if (last == 'G' || last == 'g') {
          (*value) = (*value) * (1 << 30);
        }
        return true;
      }
    }
    return false;
  }

如果这里把 value 当成 std::atomic 处理，那么 value 至少用 exchange 来处理，而不是直接读取+赋值。虽然这第二部分对性能影响十分有限，因为它似乎只在加载时候调用

把一些读锁改为了原子变量访问，通过 perf 发现 cache miss 会翻一倍。
我的猜测是这样的（只是猜测）：原来的对基本类型的读取函数会被 inline，所以函数调用直接就是读基本类型变量本身；但是换成 std::atomic 之后，因为要调用 load，而 load 内部会有函数调用，所以指令 cache miss 概率就会提高。

[QlQlqiqi]

原调用：通常会走 rocksdb::WriteThread::CompleteParallelMemTableWriter 函数。
#2622 之后，基本不会 parallel memtable write，都是 rocksdb::DBImpl::PreprocessWrite，所以速度慢了很多