Update to Serilog 4.x, remove some allocations #247
Merged
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.
Updates to Serilog 4.x to elminate a dictionary construction using
LogEvent.UnstableAssembleFromParts()
.This gets the old
LogInformation
benchmark down from (a whopping) 1.26 KB/iteration to (a whopping) 1.17 KB/iteration.But! The
LogInformation
benchmark is flawed, constructing a number of unrelated objects and doing some structure capturing, making it not representative of the overhead imposed by this library.So, I've renamed it to
Capturing
, and its companion toCapturingScoped
, and added some new benchmarks that should be closer to real-world average usage conditions.Using Serilog.Extensions.Logging still halves throughput and more than doubles allocations compared with just using Serilog directly, but in real-world terms both setups will have pretty negligible effects on latency or GC load.
Before and After
Before (
main
)After
Updated benchmarks
The new benchmarks here compare various MEL + Serilog.Extensions.Logging scenarios to a plain
_log.Information("Hello!")
Serilog call.