On Tue, Feb 3, 2026 at 11:16 PM Steven Rostedt <[email protected]> wrote: > > On Tue, 3 Feb 2026 21:50:47 +0800 > Donglin Peng <[email protected]> wrote: > > > Testing revealed that sorting within resolve_btfids introduces issues with > > btf__dedup. Therefore, I plan to move the sorting logic directly into > > btf__add_enum_value and btf__add_enum64_value in libbpf, which are > > invoked by pahole. However, it means that we need a newer pahole > > version. > > Sorting isn't a requirement just something I wanted to bring up. If it's > too complex and doesn't achieve much benefit then let's not do it.
Thanks for clarifying. Analysis shows most enum-type btf_type have small vlen (78% ≤ 10, 95% ≤50), so I think that linear search could be acceptable. > > My worry is because "cat trace" takes quite a long time just reading the > BTF arguments. I'm worried it will just get worse with enums as well. The delay stems from `btf_find_by_name_kind`’s linear search over vmlinux BTF (10k+ types). This was resolved by adding binary search to `btf_find_by_name_kind` [1]. Performance tests [2] confirm the improvement: 1. Original funcgraph-retval: # time cat trace | wc -l 101024 real 0m0.682s user 0m0.000s sys 0m0.695s 2. Enhanced funcgraph-retval: # time cat trace | wc -l 99326 real 0m12.886s user 0m0.010s sys 0m12.680s 3. Enhanced funcgraph-retval + optimizined btf_find_by_name_kind: # time cat trace | wc -l 102922 real 0m0.794s user 0m0.000s sys 0m0.810s Binary search reduces overhead to near-negligible levels (0.794s vs. 12.886s). [1] https://lore.kernel.org/bpf/[email protected]/ [2] https://lore.kernel.org/lkml/[email protected]/ > > I have trace-cmd reading BTF now (just haven't officially released it) and > doing an extract and reading the trace.dat file is much faster than reading > the trace file with arguments. I'll need to implement the enum logic too in > libtraceevent. > > -- Steve
