Avoid unnecessary string copy when no log level is specified #10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm using hashicorp/logutils with a library that requires
log.Logger
. I think it is very useful because we can use it as a library logger. Thank you very much!However, I noticed a problem when using hashicorp/logutils with the library. If no log level is specified in the library log output, the log level will be considered a huge string and a huge string copy may occur. For example, this can be a problem when logging JSON like
{"blocks": [...]}
So I introduced a maximum length of log level string to avoid huge string copy. I think this fix never cause any functional or performance issues with existing use cases.
In addition, this fix makes it easier to treat logs without a log level as log level
""
. This is a bit tricky, but it's useful if we use hashicorp/logutils to handle both our own logs and library logs.