btf: lazy decoding of string table

[lmb]

Most of the time in parsing vmlinux BTF is spent in constructing the essentialName -> TypeID index.

1. We need to allocate a lot of strings
2. We need to do a lot of hash table lookups

Replace the hash table with a "fuzzy" index, which doesn't require allocating strings. The trade-off is that lookups now become more expensive, but that is a fine trade-off to make.

core: 1
goos: linux
goarch: amd64
pkg: github.com/cilium/ebpf/btf
cpu: 13th Gen Intel(R) Core(TM) i7-1365U
                │  base.txt   │          lazy-strings.txt           │
                │   sec/op    │    sec/op     vs base               │
ParseVmlinux      27.24m ± 1%   15.49m ±  1%  -43.15% (p=0.002 n=6)
IterateVmlinux    149.9m ± 2%   132.3m ± 15%  -11.73% (p=0.041 n=6)
InspectorGadget   35.08m ± 2%   21.28m ±  5%  -39.34% (p=0.002 n=6)
geomean           52.32m        35.20m        -32.73%

                │   base.txt    │          lazy-strings.txt           │
                │     B/op      │     B/op      vs base               │
ParseVmlinux       9.969Mi ± 0%   4.960Mi ± 0%  -50.25% (p=0.002 n=6)
IterateVmlinux     34.72Mi ± 0%   31.92Mi ± 0%   -8.07% (p=0.002 n=6)
InspectorGadget   11.994Mi ± 0%   7.169Mi ± 0%  -40.23% (p=0.002 n=6)
geomean            16.07Mi        10.43Mi       -35.10%

                │   base.txt    │          lazy-strings.txt          │
                │   allocs/op   │  allocs/op   vs base               │
ParseVmlinux      146058.0 ± 0%    162.0 ± 0%  -99.89% (p=0.002 n=6)
IterateVmlinux      272.9k ± 0%   291.5k ± 0%   +6.83% (p=0.002 n=6)
InspectorGadget    155.03k ± 0%   24.30k ± 0%  -84.32% (p=0.002 n=6)
geomean             183.5k        10.47k       -94.29%

[dylandreimerink]

🚀 cool approach with the fuzzyStringIndex. Can't find anything wrong with this.