add benchmark for real wrapper classes around a JsonBuffer

[jakemac53]

This helps us to evaluate how much extension types are actually buying us, by benchmarking against thin wrappers around maps.

There are many advantages of real wrappers, such as type checks can actually work, and we can have many different implementations.

I have a specific idea in mind here, which is that the analyzer/CFE could provide their own thin wrapper implementations of these types, which wrap the analyzer/CFE representations and implement lazy getters. This would potentially allow us to handle all the query filtering, by just lazily reading the properties we care about into a new (buffer based) representation of the object, based on the fields present in the query.

Results are as follows:

SdkMapsJsonWireBenchmark: 1896ms, 7177227 bytes
     SdkMapsBufferWireBenchmark: 1984ms, 5122684 bytes
    SdkMapsBuilderWireBenchmark: 1631ms, 4859868 bytes
      LazyMapsJsonWireBenchmark: 1099ms, 7177227 bytes
    LazyMapsBufferWireBenchmark:  590ms, 5122684 bytes
LazyWrappersBufferWireBenchmark:  424ms, 2111761 bytes
   BuilderMapsJsonWireBenchmark: 1394ms, 7177227 bytes
BuilderMapsBuilderWireBenchmark:  396ms, 2111761 bytes

     ProcessSdkMapsJsonWireBenchmark:  161ms, hash 23186292
  ProcessLazyMapsBufferWireBenchmark:  257ms, hash 23186292
ProcessLazyWrappersBufferWireBenchmark:  362ms, hash 23186292
ProcessBuilderMapsBuilderWireBenchmark:  356ms, hash 23186292

[davidmorgan]

Thanks! So if I understand correctly, the difference between e.g.

LazyWrappersBufferWireBenchmark: 424ms, 2111761 bytes
BuilderMapsBuilderWireBenchmark: 396ms, 2111761 bytes

is the cost of wrapping?

[jakemac53]

Thanks! So if I understand correctly, the difference between e.g.

LazyWrappersBufferWireBenchmark: 424ms, 2111761 bytes BuilderMapsBuilderWireBenchmark: 396ms, 2111761 bytes

is the cost of wrapping?

Yes :)