src/NLog/Internal/INoAllocationStringValueRenderer.cs (1)

36-50: LGTM! Well-designed interface for allocation-free rendering.

The interface correctly extends IStringValueRenderer and provides a clear contract where returning null signals the fast path is unavailable. This aligns with the PR's goal of reducing CPU overhead for simple string-valued attributes.

Minor nitpick: The <param name="logEvent"> documentation on line 47 is empty. Consider adding a brief description like "The log event to render."

📝 Suggested documentation improvement

         /// <summary>
         /// Renders the value of layout renderer in the context of the specified log event
         /// </summary>
-        /// <param name="logEvent"></param>
+        /// <param name="logEvent">The log event to render.</param>
         /// <returns>null if not possible or unknown</returns>
         string? GetFormattedStringNoAllocation(LogEventInfo logEvent);

src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs (1)

100-103: Consider restoring SimpleStringValue when ValueType is reset to null.

Right now it stays cleared, so a later ValueType = null loses the fast path.

♻️ Proposed tweak

-                SimpleStringValue = null;
+                SimpleStringValue = value is null ? ResolveStringValueMethod(_layout) : null;

src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs (1)

80-89: Consider avoiding repeated LINQ enumeration.

simpleLayout.LayoutRenderers.Count() and .First() enumerate the collection twice. If LayoutRenderers is IEnumerable<T> without an efficient Count implementation, this incurs overhead on each layout assignment.

♻️ Suggested optimization

 private static INoAllocationStringValueRenderer? ResolveStringValueMethod(Layout layout)
 {
-    var stringValueRenderer = (layout is SimpleLayout simpleLayout && simpleLayout.LayoutRenderers.Count() == 1) ? simpleLayout.LayoutRenderers.First() as INoAllocationStringValueRenderer : null;
+    if (layout is SimpleLayout simpleLayout)
+    {
+        using var enumerator = simpleLayout.LayoutRenderers.GetEnumerator();
+        if (enumerator.MoveNext())
+        {
+            var first = enumerator.Current;
+            if (!enumerator.MoveNext() && first is INoAllocationStringValueRenderer renderer)
+            {
+                var stringValue = renderer.GetFormattedStringNoAllocation(LogEventInfo.CreateNullEvent());
+                return stringValue is null ? null : renderer;
+            }
+        }
+    }
+    return null;
-    if (stringValueRenderer != null)
-    {
-        var stringValue = stringValueRenderer.GetFormattedStringNoAllocation(LogEventInfo.CreateNullEvent());
-        return stringValue is null ? null : stringValueRenderer;
-    }
-    return stringValueRenderer;
 }

Also, line 88 (return stringValueRenderer;) is only reached when stringValueRenderer is null, making it effectively return null;. This isn't a bug but could be simplified for clarity.

src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs (1)

67-88: Avoid double enumeration of LayoutRenderers.

Count() + First() can enumerate twice and adds LINQ overhead. Consider direct list access when there’s exactly one renderer.

♻️ Proposed refactor

-            var stringValueRenderer = (layout is SimpleLayout simpleLayout && simpleLayout.LayoutRenderers.Count() == 1) ? simpleLayout.LayoutRenderers.First() as INoAllocationStringValueRenderer : null;
+            INoAllocationStringValueRenderer? stringValueRenderer = null;
+            if (layout is SimpleLayout simpleLayout && simpleLayout.LayoutRenderers.Count == 1)
+            {
+                stringValueRenderer = simpleLayout.LayoutRenderers[0] as INoAllocationStringValueRenderer;
+            }
             if (stringValueRenderer != null)
             {
                 var stringValue = stringValueRenderer.GetFormattedStringNoAllocation(LogEventInfo.CreateNullEvent());
                 return stringValue is null ? null : stringValueRenderer;
             }
             return stringValueRenderer;

src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs (1)

72-73: Compute SimpleStringValue cache when ValueType is string type, not just when null.

The cache is inconsistently managed: it's only set when ValueType is null, but the codebase treats typeof(string) equivalently (see lines 134, 224, 237). When ValueType is explicitly set to typeof(string) or reset to null, the optimization cache is skipped, reducing performance for the common string type scenario.

Apply the same cache logic to both the Layout setter (line 72) and ValueType setter (line 102):

♻️ Suggested update

-                SimpleStringValue = ValueType is null ? ResolveStringValueMethod(_layout) : null;
+                SimpleStringValue = (ValueType is null || typeof(string).Equals(ValueType))
+                    ? ResolveStringValueMethod(_layout)
+                    : null;

-                SimpleStringValue = null;
+                SimpleStringValue = (value is null || typeof(string).Equals(value))
+                    ? ResolveStringValueMethod(_layout)
+                    : null;

Also applies to: 101-102