Rolf Kristensen

I would probably create a new Layout / LayoutRenderer with lots of option for configuring the 3rd party json library along with having nuget dependency

> Then what's the point of IJsonConverter? We don't need it then? :| We need it in the formatting of the message-template with `@`, but there you don't use `RequiresJsonEscape`...

After seeing this issue #3922 where a user wants to pass on some of the Layout-options to the custom Json-Serializer (And maybe also add some extra). Then I think one...

Think this issue should be closed as resolved, as the DefaultJsonSerializer is not referenced directly anymore. Except for very specific LayoutRenderers that doesn't depend on the actual JsonSerializer-configuration.

Seems that the issue has been reduced to JSON-specific-escape-operation are depending on NLog own DefaultJsonSerializer. But all all operations that handles actually JSON-object-serialization are actually correctly handled by injected `IJsonConverter`.

Just like `ThreadAgnostic` and `MutableUnsafe` is hard. Then `IRawValue` is also hard to optimize for async-usage. Lots of traps that gives unexpected behavior. NLog-core is usually good at handling these...

> I think it would be nice if we could drop this (from SimpleLayout): That sounds like a different issues, than the bug presented here. But if you want to...

The bug in TryGetRawValue for ObjectPathRendererWrapper also exists for EventPropertiesLayoutRenderer when using objectpath. I guess until a proper solution for Precalculate has been found, then TryGetRawValue should always return false...

An optimized method for just doing one thing, will always win over a general solution that can be configured to do a lot of things. NLog 5.0 should [handle 500.000...

If you can provide an example with source-code of a performance test, then I don't mind taking a look. The performance numbers that I linked to is from Intel I5-6500...