belugabehr

Ya, all the unit tests pass, but I definitely see some flaws in my attempt here. Do not commit.

@garydgregory Weird timing that I just happened to pick up CSV commons work the other day. I thought I was making big progress on performance, but my research just revealed...

I'm going to close this. I think a push-back buffer is cleaner as it's really well suited for this use case, but the current implementation is faster (and not all...

@eolivelli I just ran some JMH tests against logging with DEBUG disabled: ``` Benchmark Mode Cnt Score Error Units Driver.logGuardsOne thrpt 5 246381456.066 ± 4270444.744 ops/s Driver.logGuardsThree thrpt 5 244367801.436...

Hello and thank you for the discussion. I think the reason parameterized logging was introduced in the first place was to avoid having to use guards and that it should...

And if you check the docs, parameterized logging is only discussed in the context of DEBUG logging. http://www.slf4j.org/faq.html#logging_performance On Sun, Jan 5, 2020, 11:28 AM David Mollitor wrote: > Hello...

We'll have to agree to disagree on this point. Guards are just boilerplate and add a lot of noise to the codebase. I'd say that it's better to have clean...

Not to mention how many times I've seen the following: if (log.isDebugEnabled()) { log.trace("msg"); } On Mon, Jan 27, 2020, 7:36 AM David Mollitor wrote: > We'll have to agree...

@eolivelli Wondering if you could take a look at this again with fresh eyes before 3.7.0

@anmolnar Are you able to take a peek at this one too? Thanks!