adding string search for event-convert processor?

[hellt]

what if we add a basic string search for event-convert processor? Can it be that at scale, using a regexp search is less efficient for a simple task like find octets at the end of a string?

Maybe to do some perf comparison?

[karimra]

benchmarked by adding a StartWith config option to convert processor.

    event_convert_test.go:395: processor: &{Values:[] StartsWith:name Type:uint Debug:false values:[] logger:0xc0000980a0}
BenchmarkConvertToUint/uint_convert
BenchmarkConvertToUint/uint_convert              1326715               983 ns/op             192 B/op          6 allocs/op
PASS
ok      github.com/karimra/gnmic/formatters/event_convert       2.528s

    event_convert_test.go:395: processor: &{Values:[^name.*] StartsWith: Type:uint Debug:false values:[0xc000232140] logger:0xc000108050}
BenchmarkConvertToUint/uint_convert
BenchmarkConvertToUint/uint_convert              1112217              1217 ns/op             176 B/op          6 allocs/op
PASS
ok      github.com/karimra/gnmic/formatters/event_convert       2.736s

[hellt]

looks like it is not drastic, but noticable? Considering that processors are applied to every value of every event, the cumulative gain might be desirable

[karimra]

This case is a bit faster but has a bigger memory footprint.
In general it depends on the type of regex.