so it's a matter of if strings.HasSuffix is faster than bytes.ContainsRune

That is what I meant. Instead of looping through every rune in the string it only needs to check the last one.

And testing "contains-[" should be more stable than testing "suffix-]", in case Linux adds new fields at the end.

That is what I had feared

This is a nice band-aid, but conflicts with what #1578 is trying to do. Reading this PR here made me realize the proposal in #1578 is even slower and more expensive, that will need to be improved, and we shouldn't have multiple ways of scanning kallsyms.

As an experiment, I wrote a naive barebones line parser for kallsyms that calls bytes.IndexAny(line, " ") repeatedly and re-slices the line:

func parseLine(line []byte) (addr uint64, name string, mod string, error)

I got your results down to this, basically cutting down another 3/4 of the size and number of allocations:

BenchmarkKernelModuleMemory-16    	       5	 220576087 ns/op	13158904 B/op	  148693 allocs/op

Note: this similarly skips lines containing [ and looks for tT symbol types only.

Perhaps we can write a simple kallsyms iterator on top of bufio.ReadLine (not using bufio.Scanner() since it allocates a ton). I'm not sure if we need to deal with utf-8 for splitting on space and \t. Having one iterator that can jump to the next line or word boundary would be ideal.

func (s *Scanner) NextLine() bool
func (s *Scanner) NextWord() bool

// These only return the current word, never a full line.
func (s *Scanner) WordBytes() []byte
func (s *Scanner) WordText() string

This avoids having to allocate an individual bufio.ScanWords scanner around a bytes.Reader for every line, since we have many short lines we need to parse into a (uint64, string) or (uint64, string, string) if it involved a kmod. If we need to filter out certain symbol types, we can call s.NextLine() if we're not interested in the remainder of the line. What we need to avoid is allocating slices and letting them escape to the heap, which is something bytes.Fields does in spades. Returning [][]byte should always result in 4 or 5 slice headers and a backing array for the outer slice being put on the heap.

I rebased my PR to fix the conflict with #1578.

Your idea of custom scanner/iterator looks interesting. Is it something you want to write after this PR gets merged?

@alban Closing this in favor of #1588. It reduces allocs more or less to the same degree.