And one more thing. I don't want to overgeneralize (and please correct me if i'm wrong) but I suspect that most common usage pattern here suggests not so many DecodingLayer-s in a single DecodingLayerParser. Most of the time, up to ten layers is enough.

If that's true, naive linear search of DecodingLayer beats map, my laptop (Core i5-3320M) tests:

BenchmarkSearchMap3-4       	30000000	        50.4 ns/op
BenchmarkSearchMap5-4       	30000000	        56.2 ns/op
BenchmarkSearchMap10-4      	20000000	        73.2 ns/op

BenchmarkSearchArray3-4     	30000000	        40.2 ns/op
BenchmarkSearchArray5-4     	30000000	        39.3 ns/op
BenchmarkSearchArray10-4    	30000000	        39.5 ns/op

BenchmarkSearchLinear3-4    	30000000	        45.2 ns/op
BenchmarkSearchLinear5-4    	30000000	        50.0 ns/op
BenchmarkSearchLinear10-4   	30000000	        52.8 ns/op

That's a definite win if some custom LayerType values are in use, so you don't want to use array indexing (too big values).

And, in case of a simple Eth->IPv4->TCP packet, about 60-70% of DecodeLayers() call duration amounts to searching for an appropriate DecodingLayer rather than layer decoding itself.

I will investigate other ways to boost performance and will return later.

Hey, yerden,

This looked super promising; is there a reason the PR was closed out?

Well, other ideas came up to me, like:

1. DecodingLayerParser doesn't consider level of a layer. For example, LayerTypeEthernet may encounter at the beginning only, rather than in the middle of a packet, so when looking for the first level decoder, layers.Ethernet should be the primary suspect to test against.

2. As I said earlier, in case we have only few decoders, linear search is preferable to map.

3. Proposed approach is good when using gopacket-owned LayerType values but it doesn't work when working with custom LayerType values. Maybe we should implement different array for values >1000.

4. Maybe we could provide end-user with a tool to supply his own map implementation for LayerType->DecodingLayer lookup. This would require to break API.

So... I thought I should take a break, test these ideas and revisit later. Or, alternatively, I can simply reopen this PR, allow it to merge and work on it for next PR. Any ideas?