Improve API around transforming loggers

[morgen-peschke]

Inspired by the tedium of #835

[rossabaker]

I have imagined something like this, but it does result in a switch statement on every logging operation, at least for the common slf4j backend. Does anybody have an inkling of the performance impact of this?

[morgen-peschke]

I have imagined something like this, but it does result in a switch statement on every logging operation, at least for the common slf4j backend. Does anybody have an inkling of the performance impact of this?

I'm not sure, though I'm optimistic.

Since there's already at least 1-2 conditionals per logging operation (checking the log level, and if to restore or clear the MDC, in addition to whatever goes on inside the MDC and Log4J) my gut-check is it won't be enough to move the needle 🤞🏻

I don't think we have timing checks on the log messages performance tests, though #850 would be a great place to add those (not sure what that would look like, how many messages do we expect to be able to reliable log in a tight loop within N seconds?)

[rossabaker]

Yeah, any performance metrics here risk falling into the same trap we see in the IO world: the speed of successive flatMaps can matter while the IO is trivial, but the speed of a gajillion flatMaps is insignificant in the vastness of a real network IO.