optimize the log formatter #552
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
optimize formatting of diagnostic messages
|
Thanks, there is a lot of impressive work here (or at least it would have taken me a long time to write and debug the string parsing methods). Merging now. |
|
thank you :). I'll have a look at others possible optimization hotspot, as I'm still wondering the reason of the issue #551 . |
|
We're having what seems to be a race condition in our tests, which run in parallel in different threads : I will put up a test case which reproduces the problem |
|
hi @testinfected , you are totally right: code: public static void main(String[] args) throws Exception {
int p = 20;
CountDownLatch latch = new CountDownLatch(p);
for (int i = 0; i < p;i++) {
new Thread(() -> {
latch.countDown();
try {
latch.await();
XRLog.log(Level.SEVERE, LogMessageId.LogMessageId0Param.CASCADE_IS_ABSOLUTE_CSS_UNKNOWN_GIVEN);
} catch (InterruptedException e) {
}
}).start();
}
}is enough to reproduce the error |
|
@testinfected I'll open a new issue so we can track it better. |
|
Thanks @syjer! |
|
I've opened the issue #646 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Hi @danfickle , this PR try to optimize JDKXRLogger and especially the XRSimpleLogFormatter.
On the JDKXRLogger, we keep a Map so we don't need to go through
Logger.getLoggerwhich is kinda slow.On the XRSimpleLogFormatter side, the biggest win is to avoid calling if necessary:
Both the
recordmethods call internallyinferCallerwhich it has is own complexity.To identify which of the parameters are effectively used for the format, I went to the "ugly" route as I'm not aware of any API to check if a parameter is present or not.
I've also aligned the default from the configuration file (see Configuration.valueFor( "xr.simple-log-format") at the bottom).
Generally all this work avoid the quite heavy stacktrace walking, which could be quite long in the cases of deeply nested tables.
Additionally, I've optimized also the formatting of the "diagnostic" message. I've removed the use of String.format. See
LogMessageIdFormat: this will avoid to callString.format(MESSAGE_FORMAT_PLACEHOLDER.matcher(logMessageId.getMessageFormat()).replaceAll("%s"), args);on each message formatting, which is used quite often if the user use the jdklogger.