Logrus: Is there a planned roadmap for performance to catch up with uber-go/zap?

[penhauer-xiao]

I am looking forward to it

[shahofblah]

Has this been fixed?

I see 2 solutions here

1. Writer contention should be the only thing restricting concurrent access
2. Instead of a JSON marshal happening for every line of log, maybe a string formatting can be done instead? This is easy if the log object is only 1 level deep.

Another question

When calling log.SetOutput(), does logrus rely on the io.Writer to synchronise access to the file or does it synchronise calls to the writer on its own?

In my service I use lumberjack downstream from logrus to provide log rotation. Would this result in the same performance hit(lumberjack synchronises writes to the file. logrus additionally synchronising calls to the writer, in this case, would be superfluous)?

[dgsb]

No this has not been fixed because it has not been reported yet as an issue here.
We may create a dedicated performance project to check how to catch up with other logging library.
However, I suspect this is going to be hard without any massive interface change.
Regarding the JSON marshalling, there is another Formatter which just output text based on sprintf formatting.

[penhauer-xiao]

@dgsb Great ！

[ghost]

zerolog is now faster than zap. logrus is left behind, performance-wise :(
since it is one of the most used logging libraries, even grpc has "official" support in grpc-middleware, it would be preferable to get a performance-optimized interface-compatible rewrite.