I just realized that LogEvent is a public class so I can't really change its API as I thought.

You may use https://www.nuget.org/packages/Microsoft.Extensions.ObjectPool/ out of the LogEvent class.

LogEvent/LogEventPropertyValue are indeed good candidates for pooling. Pooling requires some changes in APIs though but non-breaking ones.

Unfortunately it also seems that LogEvent instances might be collected by enrichers and sinks (like in some unit tests) which makes it impossible to automatically determine when they are free to be returned to the pool.

My next best idea is to make them readonly structs that are passed around as in parameters. I am not sure if that approach works with all the supported frameworks and it would also be a small but breaking change to the public API.

I've been some distance down this path in a "Serilog v3" - in a nutshell, changing LogEvent to a struct would pretty much destroy the entire ecosystem (no existing sink packages etc. would work 😄), so a different approach using a new struct type for internal event routing, and conversion to LogEvent for existing sinks/APIs would be needed.

Got this working, but there's a lot of complexity and churn for a comparatively modest improvement in throughput. Concluded that it's probably not worthwhile at this point, though it's something I have regularly come back to.

Unfortunately it also seems that LogEvent instances might be collected by enrichers and sinks (like in some unit tests) which makes it impossible to automatically determine when they are free to be returned to the pool.

This does not mean that caching is impossible. It is possible, you just need to provide this feature as opt-in.

LogEvent instances with its internal dictionaries are the most memory consuming things in the most common case.

Enrichers are sync in most cases. Sinks may be async, yes. Look into [I]Logger.Write method.

var logEvent = new LogEvent(logTimestamp, level, exception, parsedTemplate, boundProperties);
Dispatch(logEvent);

Good candidate for caching especially for those who do not use asynchronous sinks. Just acquire log event from the pool before Dispatch, fill it with needed info and return into pool after Dispatch.

@nblumhardt I can post a draft PR to evaluate.

I think that is what I tried making in this branch of mine: https://github.com/igor84/serilog/tree/reusablelogevent. If you check that out and try it out you will find a number of unit tests failing because they are collecting LogEvents and checking them at the end where they turn out wrong because they were reused.

My implementation works since caching is opt-in feature. I will post demo PR some time later.

#1788