Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add func GetLevel() uint32 in package logx/logc #4595

Closed
studyzy opened this issue Jan 23, 2025 · 2 comments · Fixed by #4603
Closed

feat: add func GetLevel() uint32 in package logx/logc #4595

studyzy opened this issue Jan 23, 2025 · 2 comments · Fixed by #4603

Comments

@studyzy
Copy link
Contributor

studyzy commented Jan 23, 2025

Is your feature request related to a problem? Please describe.
User's business code don't know current log level, need a function to get it.

Describe the solution you'd like
Add function:

func GetLevel() uint32

How to use
User can write debug log info when need it:

if logx.GetLevel() == logx.DebugLevel { // don't run below code when >= INFO level
	data, _ := json.Marshal(obj)
	logx.Debugf("your data is %s", string(data))
}
studyzy added a commit to studyzy/go-zero that referenced this issue Jan 23, 2025
@kevwan
Copy link
Contributor

kevwan commented Jan 23, 2025

You can just use Debug series of functions.

@studyzy
Copy link
Contributor Author

studyzy commented Jan 23, 2025

I understand your suggestion to use Debugf or Debug directly and let the configuration control the log level. However, I would like to further explain the motivation behind this proposal.

In some scenarios, the preparation of log content can be computationally expensive, such as when serializing large objects to JSON or performing other complex operations. For example:

logx.Debugf("Debug data: %s", expensiveComputation())

Even if the current log level is INFO and the debug message will not be printed, the function expensiveComputation() is still executed, leading to unnecessary performance overhead. This is particularly problematic in performance-sensitive applications.

By introducing a GetLevel() function, developers could check the current log level before preparing the log content, thereby avoiding the overhead entirely:

if logx.GetLevel() == logx.DebugLevel {
    data, _ := json.Marshal(largeObject)
    logx.Debugf("Debug data: %s", data)
}

This approach provides a significant performance improvement in cases where the preparation of log content is non-trivial.

Additionally, many other logging libraries implement similar functionality for the same reason:

  • Logrus provides Logger.IsLevelEnabled(level) to check if a specific log level is active.
  • Zap offers the Check method to efficiently determine whether a log should be written.

Adding GetLevel() to go-zero's logx would be a non-breaking enhancement that remains fully compatible with the current design while giving developers more flexibility and control in performance-critical applications.

studyzy added a commit to studyzy/go-zero that referenced this issue Jan 23, 2025
kevwan pushed a commit to studyzy/go-zero that referenced this issue Jan 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants