Added C++ benchmark.

[haberman]

Here are initial benchmark results:

Run on (12 X 3201 MHz CPU s)
2016-05-11 17:49:45
Benchmark                                     Time           CPU Iterations
---------------------------------------------------------------------------
google_message1_proto2_parse_noarena        274 ns        274 ns    2773101   792.218MB/s
google_message1_proto2_parse_arena          996 ns        993 ns     707578   218.903MB/s
google_message1_proto2_serialize            155 ns        156 ns    4489021   1.36459GB/s
google_message1_proto3_parse_noarena        520 ns        519 ns    1268185   419.151MB/s
google_message1_proto3_parse_arena         1204 ns       1205 ns     604370   180.504MB/s
google_message1_proto3_serialize            293 ns        292 ns    2403943   722.365MB/s
google_message2_parse_noarena            125942 ns     126397 ns       5557   638.088MB/s
google_message2_parse_arena              284564 ns     285310 ns       2464   282.683MB/s
google_message2_serialize                 94871 ns      94737 ns      10123   851.324MB/s

[haberman]

Review to @xfxyjwf.

[haberman]

retest this please

[xfxyjwf]

In the ArenaParseFixture, a new message is created in every parsing loop, however, in this NoArenaParseFixture, you are reusing the same message. A more fair comparison is probably recreating the message in this parsing loop as well.

If we want to benchmark the case where a message is reused, I guess we can change the ArenaParseFixture to something like:

Arena arena;
Message* m = Arena::CreateMessage<T>(&arena);
while () {
  const std::string& payload = payloads_[i.Next()];
  total += payload.size();
  m->ParseFromString(payload);
  if (counter++ % kArenaThreshold == 0) {
    arena.reset();
    Message* m = Arena::CreateMessage<T>(&arena);
  }
}

[haberman]

To make this more fair, I split the "NoArena" case into two: one that creates a message from scratch (parse_new) and one that reuses an existing message (parse_reuse).

I'm not sure it makes sense to allocate multiple top-level messages in a single arena, but reset it periodically. Does anybody use arenas this way?

If you can point me to some real-world uses of arena that work this way, I'll update the benchmark (or maybe add a new one for that pattern).

[haberman]

Ping @xfxyjwf , cc @gerben-s.

[haberman]

Results on my desktop:

Run on (12 X 3201 MHz CPU s)
2016-09-23 10:49:28
Benchmark                                      Time           CPU Iterations
----------------------------------------------------------------------------
google_message1_proto2_parse_new             602 ns        604 ns    1150294    359.99MB/s
google_message1_proto2_parse_reuse           255 ns        254 ns    2665418   855.155MB/s
google_message1_proto2_parse_newarena        926 ns        926 ns     769950   234.796MB/s
google_message1_proto2_serialize             165 ns        165 ns    4214354   1.28456GB/s
google_message1_proto3_parse_new             828 ns        825 ns     855202   263.405MB/s
google_message1_proto3_parse_reuse           471 ns        470 ns    1476628   462.167MB/s
google_message1_proto3_parse_newarena       1046 ns       1049 ns     659339   207.186MB/s
google_message1_proto3_serialize             231 ns        232 ns    2993231   909.373MB/s
google_message2_parse_new                 318212 ns     317106 ns       2223   254.338MB/s
google_message2_parse_reuse               113398 ns     113764 ns       6129   708.942MB/s
google_message2_parse_newarena            252076 ns     252894 ns       2802   318.918MB/s
google_message2_serialize                  65855 ns      65689 ns      10722   1.19901GB/s

[xfxyjwf]

LGTM

Please squash the commits before merging.

[gerben-s]

(value + 1) % limit

[haberman]

I think what I currently have is much faster. "limit" isn't a compile-time constant, so % will turn into a real idiv instruction, which is very slow. Mine is a single extremely predictable branch.

[gerben-s]

I consider this the wrong abstraction of the above one-liner.

If you want to do this wrapping as an abstraction than just abstract the whole payload.

const string& NextPayload() { ...}

[haberman]

I disagree. I think what I have is simpler. It doesn't need to know anything about the type or storage or lifetime of the things being iterated over. It is just a simple wrapping counter.

[gerben-s]

LGTM overall minor comment