pkg/log: Avoid unnecessary mutex lock/unlock

[ShevaXu]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go1.8

What operating system and processor architecture are you using (go env)?

darwin/amd64 & linux/amd64

What did you do?

I found func (l *Logger) Output(calldepth int, s string) error in pkg/log had a strange lock-then-unlock logic for the expensive runtime.Caller(calldepth).

I tried to remove this lock-unlock logic and benchmark it, which results in ~20% improvement for concurrent logging with flags Lshortfile or Llongfile (tested on both darwin&linux).

Benchmark suit here: https://github.com/ShevaXu/bench-log

[mvdan]

As someone not familiar with neither the log package nor runtime.Caller, are you sure the lock isn't there for a particular reason? Did you try git blame?

[ShevaXu]

git blame shows commit 6075206 log: more locking did add this lock to guard prefix & flag. I think it has its point.

I was just curious how this would hurt log performance, and whether it is insignificant for most cases.

[ianlancetaylor]

I'm going to close this because I don't think there is anything to do here. We can't simply remove the lock, or we would get race conditions if one goroutine logs while a different goroutine calls SetFlags.

[ShevaXu]

I think the race conditions caused by removing the lock would not cause any bug or un-expected in real scenarios. Thanks for the discussion anyway.

[mvdan]

@ShevaXu making the log package not thread-safe would break backwards compatibility, so it's not an option.

In any case, if what you need is performance in your log calls, you'd probably want to write custom code instead of using the standard logger.