protobuf中会严重影响时间和空间损耗的地方

当前项目中普遍用到GOOGLE 的一个开源大作PROTOBUF，把它作为网络应用层面的传输协议，至于它的诸多优势这里不作多说了！直接入正题！
前几日在PROTOBUF上面有严重的效率和空间开销的问题，没想到这两大难题一下子都来了，来得真是“迅雷不及掩耳之势”！跟踪后发现问题出在了“嵌套的MESSAGE个数过多，时间开销基本上全花在了ADD message上面”，例如：
message B{
标记 类型 变量 ＝ 序列号；
...
}
message A{
repeated B f = 1;
}
A a;
这里message A中有上百万个message B，时间开销基本花在了 a.add_f()上面，而且空间上面开销也比较大。
针对这个头疼的问题，头这几天也在着急，项目都进行到这儿出了这等问题!之前我一直怀疑我们的策略问题，这几天在头儿的指示下，研究了一下PROTOBUF的源码，了解其中部分实现体制。这里简单地跟大家分享一下，大家尽管把砖头拍过来，嘿嘿！^_^
protobuf针对required 标记的字段分了两类，对每类都有相应的处理方式。其一：MESSAGE STRING；其二：非MESSAGE 和STRING，即原始数据类型，如INT32 INT64 FLOAT 等。我们把它们称为：repeated message(或者string)和repeated raw(原始数据类型）两种。PROTOBUF针对前者对内存的管理是，每次ADD时都会NEW一次；而后者先预分配了4个空间，随后成倍地动态增长空间（这个过程包括分配新空间，把原先的数据挪过来，再释放之前的旧空间三个操作）；
虽然前都也有预先分配空间和动态增长空间，但分配的是用来存放MESSAGE或者STRING对象地址的空间，每次ADD的时候仍然要为数据分配空间。
下面把其中的一些实现细节贴出来，对比看一下：
repeated message(或者string)类的定义：

template <typename Element>
class RepeatedPtrField : public internal::RepeatedPtrFieldBase {
 public:
  RepeatedPtrField();
  RepeatedPtrField(const RepeatedPtrField& other);
  ~RepeatedPtrField();

RepeatedPtrField继承了RepeatedPtrFieldBase类的一些比较重要的成员如下：

 

static const int kInitialSize = 4;

  void** elements_;
  int current_size_;
  int allocated_size_;
  int total_size_;

  void* initial_space_[kInitialSize];

上面的几个成员的定义在RepeatedPtrFieldBase类里面。

repeated raw（原始数据类型）类的定义：

template <typename Element>
class RepeatedField {
 public:
  RepeatedField();
  RepeatedField(const RepeatedField& other);
  ~RepeatedField();
。。。。
点击(此处)折叠或打开
								
							
							
								private:
  static const int kInitialSize = 4;

  Element* elements_;
  int current_size_;
  int total_size_;

  Element initial_space_[kInitialSize];
							
						
。。。

elements_就是据说的预分配数组，初始数组元素的个数是kInitialSize,就是4.
current_size_表示当前已经占用的元素个数
total_size_表示当前数组总大小
注意：这两个类中的成员 elements_的类型的区别，前者，用来存放的是message或者string对象空间的地址；后者用来存放的是真正的数据地址。

repeated message(或者string)对ADD的处理方式：

template <typename Element>
inline Element* RepeatedPtrField<Element>::Add() {
  return RepeatedPtrFieldBase::Add<TypeHandler>();
}

template <typename TypeHandler>
inline typename TypeHandler::Type* RepeatedPtrFieldBase::Add() {
  if (current_size_ < allocated_size_) {
    return cast<TypeHandler>(elements_[current_size_++]);
  }
  if (allocated_size_ == total_size_) Reserve(total_size_ + 1);
  ++allocated_size_;
  typename TypeHandler::Type* result = TypeHandler::New();
  elements_[current_size_++] = result;
  return result;
}

void RepeatedPtrFieldBase::Reserve(int new_size) {
  if (total_size_ >= new_size) return;

  void** old_elements = elements_;
  total_size_ = max(total_size_ * 2, new_size);
  elements_ = new void*[total_size_];
  memcpy(elements_, old_elements, allocated_size_ * sizeof(elements_[0]));
  if (old_elements != initial_space_) {
    delete [] old_elements;
  }
}

别看这里有动态增长内存空间，它这是做戏给人看的！它这里动态增长的是对象（习惯把message string称作“对象”，把原始类型称作“数据”，其实在C++眼里都是对象，只是本人癖性用C的眼光去看，^_^）地址空间，并不是真正的数据空间！

repeated raw（原始数据类型）对ADD的处理方式：

template <typename Element>
inline Element* RepeatedField<Element>::Add() {
  if (current_size_ == total_size_) Reserve(total_size_ + 1);
  return &elements_[current_size_++];
}

template <typename Element>
void RepeatedField<Element>::Reserve(int new_size) {
  if (total_size_ >= new_size) return;

  Element* old_elements = elements_;
  total_size_ = max(total_size_ * 2, new_size);
  elements_ = new Element[total_size_];
  MoveArray(elements_, old_elements, current_size_);
  if (old_elements != initial_space_) {
    delete [] old_elements;
  }
}

这里才是真正的动态增长数据空间。也就是说，只有第5、9、17、33。。。第N次%（2的M次方）==1时，才会重新去分配内存。
到这里，问题已经找到了，那么只能针对这里的两种特性来对我们的“应用协议”（PROTO文件中体现出来的应用架构）做一下协调、更改，可以避免repeated message(或者string)当repeated次数比较多的时候。！
我们相应地修改了一下PROTO文件，最终测试，发现时间上的开销果真缩小到了1/10左右，空间倒是没有减少多少，但多少还是少了一点儿！^_^ 唉！毕竟鱼和熊掌不可兼得，就时间和空间在软件这方面的地位而言，自古就是“难全”的，往往有一个要做出牺牲的！！！
其实去年就PROTOBUF的应用学习过一个月，还学习过一些比较高级的用法，但是并没有深入源码去理解它的实现机制，也没有去过多的去考虑它的性能问题！之后以为，PROTOBUF这个东西比较高级、比较好用，到现在知道再高级实用的东西也会有点瑕疵的，但瑕疵一般不会贴在脸上，还等着我们去发现，去适应它或者索引丢弃它不要！