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 to CapturingScoped, 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.
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.