I'm home with COVID at the moment and not in a position to do any performance analysis today.

But I'm not very happy about adding a logger parameter everywhere and passing it on every function call. This code is designed to be as fast as possible.

The printf you're complaining about iin #14467 is telling you that you gave it bad data -- the example code in the bug (please link the bug with # before the bug number in the original so that GitHub does the right things with it!) is telling you that attributes["foo"] is not a string but you're comparing it to one.

In the original version of this code, I didn't have the printf at all, and then was asked to include it because we should generate some.

I guess if we think we need it, I would much prefer to move all of the functions here into member functions on the parser. There are also benchmarks in compare_test.go that I'd want to run a before/after comparison with, whichever path we take.

And finally, I don't believe that either transformprocessor or ottl has introduced a logger before. If we do, I don't think I want to depend on zap as the standard logging interface; I would prefer a more generic choice, especially now that there's some consideration going on in the Go community towards a more flexible standard logging model. Given that this is just a single call, I'd suggest we start with the Go standard log interface, or even define a logger interface locally that we can tweak over time.

@TylerHelmuth do you have an opinion on any of this?