-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
NLog 4.5 changelog #2325
Comments
Thank you very much! |
Performance Comparison of NLog 4.4 and NLog 4.5. Most of the performance improvements disappears in the extra overhead of the new MessageTemplate-parser, but one can still see the reduced memory allocation. One can also get a glimpse of the extra overhead introduced by parsing the message-template, and capturing the message-properties (NLog45-MT). The memory allocation increases along with the CPU-time. Still the differences is so small, so I don't think anyone will actually notice 😃
|
looks good! MT will be only a good option if you're really using structured logging, isn't? |
are the message count per thread? as more threads = slower? (comparing the 8 threads to the 4 and 2) |
Yes very happy about not having ruined performance completely for all existing users. And also very happy about giving good performance to those who wants to explore structured-logging.
NLog45-MT is the same configuration as NLog45-Auto. I have just changed the performance-tester to generate structured-logging test-messages, so it starts to capture the message-properties (Activates the entire MessagetTemplate-Parser engine for real) |
The message count is the same. Just more threads calling the logger-object concurrently. This gives an overhead when multiple threads are hitting the same target, thus slowing performance (waiting for the other threads to leave the target). You can see the non-sync-tests performs better when going from 1 thread to 2 threads, but when reaching 4 threads then the target-monitor-lock starts to hurt. The monitor-lock is needed to protect the layoutrenderers as not all can handle multiple threads. I tried to minimize the scope of the target-lock with #1700 I guess one could consider replacing the lock-queue on the async-wrapper with the concurrentqueue, when using NetStandard2.0. But all earlier version of ConcurrentQueue actually performs worse than lock-queue, and those versions also generate a lot of extra allocations. This will help when all layout doesn't use layoutrenderer that require precalculation (See SimpleLogger-tests) But again it is seldom that multi-threaded applications are so aggressive about logging, that their bottleneck becomes the NLog-targets. Usually threads seldom meet each other inside NLog. |
@snakefoot do you like to write a post on nlog-project.org for this? (http://nlog-project.org/archives/) |
Think you are doing a great job already. And the MessageTemplate logic is your creation.
|
See https://github.com/NLog/NLog/blob/master/CHANGELOG.md @snakefoot |
Update changelog
The text was updated successfully, but these errors were encountered: