Reviewing files that changed from the base of the PR and between 36943d3 and 34af77b.

• src/NLog/ILoggerExtensions.cs (6 hunks)
• src/NLog/Internal/LogMessageTemplateFormatter.cs (6 hunks)
• src/NLog/LogEventInfo.cs (2 hunks)
• src/NLog/LogFactory.cs (2 hunks)
• src/NLog/Logger-V1Compat.cs (30 hunks)
• src/NLog/Logger-generated.cs (48 hunks)
• src/NLog/Logger-generated.tt (8 hunks)
• src/NLog/Logger.cs (15 hunks)
• src/NLog/MessageTemplates/LiteralHole.cs (1 hunks)
• src/NLog/MessageTemplates/TemplateEnumerator.cs (1 hunks)

src/NLog/MessageTemplates/TemplateEnumerator.cs (1)

57-57: LGTM - Adding property accessor for template string.

The newly added Template property provides external access to the original template string being parsed, which can be useful for components that need to access the raw template string directly.

src/NLog/MessageTemplates/LiteralHole.cs (1)

59-59: Good optimization for struct parameter passing.

Using the in keyword for struct parameters is a performance improvement that avoids copying the struct values when passed to the constructor. Since Literal and Hole are structs, this reduces memory allocations and improves performance in code paths that create many LiteralHole instances.

src/NLog/ILoggerExtensions.cs (6)

255-255: LGTM - Using generic overload instead of object array.

This change improves performance by calling the generic Debug<object> method directly instead of packing arguments into a temporary object array. This reduces memory allocations, especially when logging is disabled.

---

274-274: LGTM - Using generic overload for multiple arguments.

Similar optimization for the two-argument case, calling Debug<object, object> instead of creating an object array.

---

295-295: LGTM - Using generic overload for three arguments.

Similar optimization for the three-argument case, using Debug<object, object, object> to avoid array allocations.

---

422-422: LGTM - Using generic Trace overload instead of object array.

The same optimizations applied to the Trace method, replacing object array creation with direct generic method calls.

---

441-441: LGTM - Using generic Trace overload for two arguments.

Similar optimization for the two-argument case for Trace calls.

---

462-462: LGTM - Using generic Trace overload for three arguments.

Similar optimization for the three-argument case for Trace calls.

src/NLog/LogFactory.cs (3)

72-72: LGTM - Adding field for caching LogMessageTemplateFormatter.

Adding an internal field to cache the LogMessageTemplateFormatter instance, which will support the span-based optimization improvements.

---

309-312: LGTM - Conditionally caching the message formatter.

This improvement caches the LogMessageTemplateFormatter only when message template parsing is disabled. When parsing is enabled, it sets the cache to null since each message might need different parsing logic. The SingleTargetMessageFormatter is always assigned regardless of the EnableMessageTemplateParser setting.

---

316-316: LGTM - Proper null handling in else branch.

Ensures the LogMessageTemplateFormatter field is explicitly set to null when the messageFormatter is not a LogMessageTemplateFormatter.

src/NLog/LogEventInfo.cs (2)

612-629: Approve the refactored method for enhanced readability.

The refactoring of NeedToPreformatMessage(object[] parameters) improves readability with early returns and clearer control flow while maintaining the same functionality.

---

631-648: Well-implemented span-based performance optimization.

This new overload leverages ReadOnlySpan<object> with the in modifier to avoid unnecessary array allocations, particularly beneficial when logging is disabled. The conditional compilation ensures compatibility with older frameworks while allowing modern .NET applications to benefit from this optimization.

src/NLog/Logger-V1Compat.cs (2)

722-724: Good use of the new span overload

Here the traditional IsTraceEnabled guard is retained, so no unnecessary work is done when the level is disabled. 👍

---

98-104:

Details

✅ Verification successful

Consider restoring the IsEnabled(level) guard (affects every new WriteToTargetsWithSpan call)

For the span-based branch we now gate on

var targetsForLevel = GetTargetsForLevelSafe(level);
if (targetsForLevel != null)
{ ... }

where the legacy code used a cheap IsEnabled(level) check.

If GetTargetsForLevelSafe internally performs the same check this is fine, but if it merely returns an empty array the extra lookup/allocation happens for every disabled log-call, partly defeating the allocation-saving goal of this PR.

+#if NETSTANDARD2_1_OR_GREATER || NET9_0_OR_GREATER
+            if (IsEnabled(level))   // keeps the fast short-circuit
+            {
+                var targetsForLevel = GetTargetsForLevelSafe(level);
+                if (targetsForLevel != null)
+                {
+                    WriteToTargetsWithSpan(targetsForLevel, level, null,
+                        Factory.DefaultCultureInfo, message, arg1, arg2);
+                }
+            }
+#else
             if (IsEnabled(level))
             {
                 WriteToTargets(level, message, new[] { arg1, arg2 });
             }
-#endif
+#endif

Please verify the behaviour of GetTargetsForLevelSafe (and whether it allocates) before applying – the same pattern recurs in many overloads.

---

🏁 Script executed:

#!/bin/bash
set -e
# Locate and display the implementation of GetTargetsForLevelSafe in Logger-V1Compat.cs
rg -n "GetTargetsForLevelSafe" -A15 -B5 src/NLog/Logger-V1Compat.cs

Length of output: 3758

---

🏁 Script executed:

#!/bin/bash
set -e
# Search for the definition of GetTargetsForLevelSafe across the codebase
rg -n "GetTargetsForLevelSafe" -g "*.cs" -A50 -B5

Length of output: 44095

---

No changes needed for the span-based guard

Verified that IsEnabled(level) is implemented as

public bool IsEnabled(LogLevel level) => GetTargetsForLevelSafe(level) != null;

and GetTargetsForLevelSafe simply does an array lookup (no allocations). The new code already invokes GetTargetsForLevelSafe exactly once and short-circuits on null, matching the legacy behavior without extra overhead.

src/NLog/Logger.cs (3)

254-254: Good refactor – avoids one virtual-call hop

Replacing the direct WriteToTargets invocation with the slimmer WriteLogEventToTargets helper removes an extra condition/overload resolution step and keeps all target dispatch logic in one place. Nice micro-cleanup.

---

428-456: Potential infinite recursion / ambiguous overload after signature change

Both overloads of WriteToTargetsWithSpan call each other in certain
paths, e.g.:

WriteToTargetsWithSpan(level, …)  ➜  WriteToTargetsWithSpan(targetsForLevel, …)

After the signature corrections, ensure
(1) the first overload is only a convenience wrapper that retrieves
targetsForLevel and does not re-enter the same overload chain, and
(2) there is no accidental overload hiding once params is removed.

A quick guard:

private void WriteToTargetsWithSpan(LogLevel level,…)
{
    var targets = GetTargetsForLevel(level);
    if (targets is null) return;
    // NOTE: do not call itself again – call the <ITargetWithFilterChain,…> variant
    WriteToTargetsWithSpan(targets, level, …);
}

Validate with unit tests or Roslyn analyzers to avoid stack-overflow.

---

805-806: Consistent use of the new helper—nice

Every internal WriteToTargets overload has been updated to delegate to
WriteLogEventToTargets, centralising common exception handling and
context property merging. This improves maintainability and reduces code
duplication.

Also applies to: 817-818, 827-828, 840-841, 850-851

Reviewing files that changed from the base of the PR and between 8d91243 and 59bdd55.

• src/NLog/ILoggerExtensions.cs (6 hunks)
• src/NLog/Internal/LogMessageTemplateFormatter.cs (5 hunks)
• src/NLog/LogEventInfo.cs (2 hunks)
• src/NLog/LogFactory.cs (2 hunks)
• src/NLog/Logger-V1Compat.cs (30 hunks)
• src/NLog/Logger-generated.cs (48 hunks)
• src/NLog/Logger-generated.tt (8 hunks)
• src/NLog/Logger.cs (14 hunks)
• src/NLog/MessageTemplates/LiteralHole.cs (1 hunks)
• src/NLog/MessageTemplates/TemplateEnumerator.cs (1 hunks)

• src/NLog/MessageTemplates/TemplateEnumerator.cs
• src/NLog/MessageTemplates/LiteralHole.cs
• src/NLog/ILoggerExtensions.cs
• src/NLog/Logger-generated.tt
• src/NLog/LogEventInfo.cs
• src/NLog/LogFactory.cs
• src/NLog/Logger-V1Compat.cs
• src/NLog/Logger-generated.cs

src/NLog/Internal/LogMessageTemplateFormatter.cs (5)

55-55: LGTM: Improved naming consistency with _forceMessageTemplateRenderer

The rename from _forceTemplateRenderer to _forceMessageTemplateRenderer improves naming consistency and better reflects its purpose in relation to message templates.

Also applies to: 62-69, 78-78

---

141-207: Refactored Render method for better separation of positional and non-positional holes

The refactoring creates a cleaner structure with better logical separation between positional and named template holes. The new flow correctly determines the message format type and handles template parameters accordingly.

Some key improvements:

• Initializing messageTemplateParameters to null upfront
• Clearly separating the positional template path from the named template path
• Refactoring the shared hole rendering logic to the new RenderHolePositional method
• Adding proper handling for rewind scenarios
• Improved null checks when truncating parameters

---

209-279: LGTM: New span-based Render overload for modern .NET versions

The new span-based rendering method is a good optimization that leverages ReadOnlySpan<object> to reduce allocations. It maintains the same logical structure as the array-based version while properly utilizing spans.

---

281-295: Good extraction of positional hole rendering logic

Extracting the positional hole rendering logic into a separate method is a good refactoring that improves code maintainability and readability.

---

297-312: LGTM: Simplified RenderHole methods

The refactored RenderHole methods provide a cleaner separation of concerns, with the primary method delegating to a more specialized implementation.

src/NLog/Logger.cs (3)

254-254: LGTM: Improved naming clarity with WriteLogEventToTargets

The rename from WriteToTargets to WriteLogEventToTargets provides better clarity about the method's purpose - specifically writing a LogEventInfo object to targets.

Also applies to: 272-272, 803-803, 815-815, 825-825, 838-838, 848-848, 852-890

---

413-425: LGTM: Conditional span-based logging for generic arguments

The conditional compilation approach allows efficient span-based logging for modern .NET frameworks while maintaining backward compatibility with older frameworks. The direct use of WriteToTargetsWithSpan for generic arguments avoids unnecessary array allocations.

Also applies to: 437-449, 464-476, 490-502, 519-531, 547-559

---

595-602: LGTM: Smart message formatting optimization

The WriteToTargetsWithSpan method intelligently determines whether to:

1. Defer message formatting completely
2. Convert parameters to properties for non-positional templates (skipping array allocation)
3. Fall back to traditional string.Format with array allocation for positional templates

This optimization reduces unnecessary allocations in high-throughput logging scenarios.

However, similar to the public methods, remove the params modifier:

- private void WriteToTargetsWithSpan(LogLevel level, Exception exception, IFormatProvider formatProvider, string message, params ReadOnlySpan<object> args)
+ private void WriteToTargetsWithSpan(LogLevel level, Exception exception, IFormatProvider formatProvider, string message, ReadOnlySpan<object> args)

- private void WriteToTargetsWithSpan(ITargetWithFilterChain targetsForLevel, LogLevel level, Exception exception, IFormatProvider formatProvider, string message, params ReadOnlySpan<object> args)
+ private void WriteToTargetsWithSpan(ITargetWithFilterChain targetsForLevel, LogLevel level, Exception exception, IFormatProvider formatProvider, string message, ReadOnlySpan<object> args)

Also applies to: 604-632

Reviewing files that changed from the base of the PR and between ce99697 and 12f5623.

• src/NLog/ILoggerExtensions.cs (6 hunks)
• src/NLog/Internal/LogMessageTemplateFormatter.cs (5 hunks)
• src/NLog/LogEventInfo.cs (2 hunks)
• src/NLog/LogFactory.cs (2 hunks)
• src/NLog/Logger-V1Compat.cs (30 hunks)
• src/NLog/Logger-generated.cs (48 hunks)
• src/NLog/Logger-generated.tt (8 hunks)
• src/NLog/Logger.cs (14 hunks)
• src/NLog/MessageTemplates/LiteralHole.cs (1 hunks)
• src/NLog/MessageTemplates/TemplateEnumerator.cs (1 hunks)

• src/NLog/MessageTemplates/TemplateEnumerator.cs
• src/NLog/MessageTemplates/LiteralHole.cs
• src/NLog/ILoggerExtensions.cs
• src/NLog/LogFactory.cs
• src/NLog/LogEventInfo.cs
• src/NLog/Logger-generated.tt
• src/NLog/Logger-generated.cs
• src/NLog/Logger-V1Compat.cs
• src/NLog/Logger.cs

src/NLog/Internal/LogMessageTemplateFormatter.cs (4)

55-56: Good name improvement for clarity

The renaming of the field and parameter from _forceTemplateRenderer to _forceMessageTemplateRenderer improves clarity by aligning with MessageTemplate terminology used throughout the codebase. The EnableMessageTemplateParser property update is consistent with this change.

Also applies to: 62-63, 68-69, 78-78

---

141-207: Improved message template rendering logic

The refactored Render method provides several improvements:

1. Better structure with early exit for non-message-template formats
2. Improved handling of mixed format templates with rewind capability
3. Proper null initialization and cleanup for parameter arrays
4. Do-while loop provides clearer control flow

The implementation now handles both positional and named parameters more efficiently, with proper rewinding when mixed templates are detected.

---

209-279: Good optimization for modern .NET platforms

The span-based overload for .NET Standard 2.1+ and .NET 9.0+ provides performance benefits by:

1. Accepting ReadOnlySpan<object> to avoid array allocations
2. Using the pooled StringBuilder pattern efficiently
3. Providing equivalent functionality to the array-based version

The null-check on line 268 properly prevents the potential NullReferenceException identified in a previous review.

---

281-295: Well-structured method breakdown for hole rendering

The separation of rendering logic into distinct methods improves code organization:

1. New RenderHolePositional method handles the specific case of positional holes
2. Refactored RenderHole methods provide clear overloads for different parameter types
3. Common rendering logic is properly shared

This structure supports both the original array-based and new span-based implementations efficiently.

Also applies to: 297-300, 302-312