Hello, everyone,

This is a followup to #657.

I've investigated various ways to gain some extra performance for DecodingLayerParser. In the course of it, I was pursuing these goals:

• avoid breaking API;
• avoid performance degradation in existing API;
• provide maximum flexibility to suit end-user's needs.

So, I ended up adding DecodingLayerContainer which stores DecodingLayer values and allows to address them. Various implementations of DecodingLayerContainer are also presented: DecodingLayerMap, DecodingLayerSparse, DecodingLayerArray.

DecodingLayerParser is refactored to use DecodingLayerContainer. DecodingLayerMap is used by default in current implementation as the most versatile one. Additionally, new decoding logic omits redundant lookup of the first LayerType value. From another side, additional level of indirection may impose some overhead.

Of course, the user may write his/her own DecodingLayerContainer implementation if necessary. Those in need may refer to LayersDecoder function implementation in the package.

Here are benchmark results comparing with master branch, somewhat average value taken:

benchmark                                     old ns/op     new ns/op     delta
BenchmarkDecodingLayerParserIgnorePanic-4     133           130           -2.26%
BenchmarkDecodingLayerParserHandlePanic-4     188           181           -3.72%

As you can see, the performance is nearly the same (or even slightly better) for default DecodingLayerMap container.

Some additional benchmarks added to test new containers:

BenchmarkDecodingLayerParserIgnorePanic-4               10000000               130 ns/op
BenchmarkDecodingLayerParserHandlePanic-4               10000000               179 ns/op

BenchmarkDecodingLayerParserSparseIgnorePanic-4         20000000               113 ns/op (-13.1%)
BenchmarkDecodingLayerParserSparseHandlePanic-4         10000000               163 ns/op (-8.9%)

BenchmarkDecodingLayerParserArrayIgnorePanic-4          10000000               122 ns/op (-6.2%)
BenchmarkDecodingLayerParserArrayHandlePanic-4          10000000               170 ns/op (-5.0%)

BenchmarkDecodingLayerParserMapIgnorePanic-4            10000000               130 ns/op (~)
BenchmarkDecodingLayerParserMapHandlePanic-4            10000000               178 ns/op (~)

As you can see, DecodingLayerSparse container is the fastest with standard LayerType values.

These three benchmarks show how DecodingLayerContainer may be used as a standalone layers decoding tool. As you can see, DecodingLayerParser with identical container imposes some additional overhead though adds some abstraction.

BenchmarkDecodingLayerArray-4                           20000000               118 ns/op (-3.3%)
BenchmarkDecodingLayerMap-4                             10000000               124 ns/op (-4.6%)
BenchmarkDecodingLayerSparse-4                          20000000               106 ns/op (-6.2%)

Tests were run on a laptop (Core i5-3320M), go 1.12.5. Please cross-check the results since I don't have access to another not heavily loaded physical machine.

Some caveat. LayersDecoder method in all presented DecodingLayerContainer implementations is a carbon copy of the package's LayersDecoder function so it leads to some code redundancy. It may be avoided simply by doing indirect call to LayersDecoder() but in that case the performance gains are not convincing that much. I believe it is so due to inlining done by compiler.