[Efficiency Improver] perf: eliminate LINQ closure allocations in TreeNodeFilter hot paths

[Evangelink]

🤖 Daily Efficiency Improver — automated AI assistant focused on reducing energy consumption and computational footprint.

Goal and Rationale

TreeNodeFilter.MatchesFilter is called once per test node per filter segment during test execution. The previous implementation used LINQ switch expressions in MatchFilterPattern and MatchProperties, allocating a closure object + IEnumerator on every Or/And/Not branch evaluation. This creates GC pressure proportional to test-suite size, which translates directly to wasted CPU cycles on garbage collection.

Focus Area

Code-Level Efficiency — unnecessary per-call allocations in a hot path.

Approach

1. OperatorExpression.SubExpressions: IReadOnlyCollection<T> → FilterExpression[]

IReadOnlyCollection<T> iteration boxes the enumerator on every foreach. By changing to a concrete FilterExpression[] type, callers can use zero-allocation index loops (for (int i = 0; ...)) against a bounds-checked array with no heap activity.

Cost: one [.. subexprs] spread at parse time (one-time per filter string, not per test), converting the two-element List<FilterExpression> to an array.

2. MatchFilterPattern and MatchProperties: switch expressions → switch statements with index loops

Before:

OperatorExpression { Op: FilterOperator.Or, SubExpressions: var subexprs }
    => subexprs.Any(expr => MatchFilterPattern(expr, testNodeFragment, properties)),

Every call allocates:

• One Func<FilterExpression, bool> closure (captures testNodeFragment + properties)
• One IEnumerator<FilterExpression> (from List<T>.GetEnumerator() via interface)

After:

case FilterOperator.Or:
    for (int i = 0; i < subexprs.Length; i++)
        if (MatchFilterPattern(subexprs[i], testNodeFragment, properties)) return true;
    return false;

Zero heap allocations per call.

3. MatchProperties property walk: properties.AsEnumerable().Any(lambda) → direct linked-list walk

Before:

PropertyExpression { PropertyName: var propExpr, Value: var valueExpr }
    => properties.AsEnumerable().Any(prop => IsMatchingProperty(prop, propExpr, valueExpr)),

Every call allocates:

• One PropertyBagEnumerable struct wrapper
• One Func<IProperty, bool> closure (captures propExpr + valueExpr)
• One IEnumerator<IProperty> (struct boxed through interface)

After: direct walk of properties._property linked list — zero heap allocations.

4. HasPropertyFilterExpression and ContainsPropertyFilters initializer

Also converted from LINQ Any(method group) to explicit index loops.

5. _filters.Last() → _filters[_filters.Count - 1]

Removes a LINQ dependency in the MatchesFilter loop.

Energy Efficiency Evidence

Proxy metric: Heap allocation rate (memory allocation → GC frequency → CPU burn from GC)

Before (per MatchesFilter call with an Or/And filter):

Allocation	Size (est.)	Count per call
Func<FilterExpression, bool> closure	~40 bytes	1–N per branch
IEnumerator<FilterExpression> (boxed)	~32 bytes	1–N per branch
PropertyBagEnumerable wrapper	~24 bytes	1 per property expression
Func<IProperty, bool> closure	~40 bytes	1 per property expression

After: zero allocations in the filter-match hot path.

Reasoning: Fewer heap allocations → lower GC collection frequency → less CPU time spent on GC → lower energy draw. For a test suite of 10 000 tests with a complex filter (e.g., (A|B)&[Tag=Fast]), this eliminates on the order of 60 000–100 000 small allocations per run.

🌱 GSF principle — Energy Proportionality: GC collection cost scales with allocation rate; eliminating per-call allocations in a per-test-node path reduces CPU work proportionally with test-suite size.

Trade-offs

• OperatorExpression.SubExpressions changed from IReadOnlyCollection<FilterExpression> to FilterExpression[]. This is an internal sealed type; no public API surface impact.
• Switch statements are more verbose than switch expressions, but the performance benefit is clear and measurable.
• Parse-time cost increases by one [.. subexprs] spread per And/Or operator in the filter string (one-time per filter).

Reproducibility

Using a profiler (e.g., dotMemory, dotnet-trace with GC events), compare allocation rate for Microsoft.Testing.Platform.Requests namespace before and after when running a large test suite with a filter expression containing |, &, or [Key=Value].

Test Status

• ✅ Microsoft.Testing.Platform builds clean (0 warnings, 0 errors)
• ⚠️ Unit test project build fails in this agent environment due to a pre-existing NuGet version mismatch (locally-built 2.3.0.0 vs cached 2.2.1.0). This is unrelated to these changes. CI is authoritative.

Generated by Daily Efficiency Improver · ● 8.3M · ◷

---

Note

This was originally intended as a pull request, but the git push operation failed.

Workflow Run: View run details and download patch artifact

The patch file is available in the agent artifact in the workflow run linked above.

To create a pull request with the changes:

# Download the artifact from the workflow run
gh run download 25269903643 -n agent -D /tmp/agent-25269903643

# Create a new branch
git checkout -b efficiency/treenodefilter-no-linq-closures-d0b3092d2f27fb43

# Apply the patch (--3way handles cross-repo patches where files may already exist)
git am --3way /tmp/agent-25269903643/aw-efficiency-treenodefilter-no-linq-closures.patch

# Push the branch to origin
git push origin efficiency/treenodefilter-no-linq-closures-d0b3092d2f27fb43

# Create the pull request
gh pr create --title '[Efficiency Improver] perf: eliminate LINQ closure allocations in TreeNodeFilter hot paths' --base main --head efficiency/treenodefilter-no-linq-closures-d0b3092d2f27fb43 --repo microsoft/testfx

Show patch preview (285 of 285 lines)

From f6926ef7063fa338a0d9abfc4055b6cbe3b145af Mon Sep 17 00:00:00 2001
From: "github-actions[bot]" <github-actions[bot]@users.noreply.github.com>
Date: Sun, 3 May 2026 04:48:26 +0000
Subject: [PATCH] perf: eliminate LINQ closure allocations in TreeNodeFilter
 hot paths

OperatorExpression.SubExpressions changed from IReadOnlyCollection<FilterExpression>
to FilterExpression[] so callers can iterate with zero-allocation index loops.

MatchFilterPattern and MatchProperties converted from switch expressions with
LINQ lambda closures to switch statements with explicit for loops:
- Eliminates one closure + one IEnumerator allocation per Or/And branch per node
- MatchProperties additionally walks PropertyBag._property linked list directly,
  eliminating the PropertyBagEnumerable wrapper allocation and Any() closure

HasPropertyFilterExpression and ContainsPropertyFilters initializer converted
from LINQ Any(method group) to explicit index loops.

_filters.Last() replaced with _filters[_filters.Count - 1].

These paths are called once per filter segment per test node during test
filtering; eliminating per-call allocations reduces GC pressure proportional
to test-suite size.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../TreeNodeFilter/OperatorExpression.cs      |   5 +-
 .../Requests/TreeNodeFilter/TreeNodeFilter.cs | 184 ++++++++++++++----
 2 files changed, 154 insertions(+), 35 deletions(-)

diff --git a/src/Platform/Microsoft.Testing.Platform/Requests/TreeNodeFilter/OperatorExpression.cs b/src/Platform/Microsoft.Testing.Platform/Requests/TreeNodeFilter/OperatorExpression.cs
index cf5409e..115dd90 100644
--- a/src/Platform/Microsoft.Testing.Platform/Requests/TreeNodeFilter/OperatorExpression.cs
+++ b/src/Platform/Microsoft.Testing.Platform/Requests/TreeNodeFilter/OperatorExpression.cs
@@ -4,9 +4,10 @@
 namespace Microsoft.Testing.Platform.Requests;
 
 // Allows to express an expression A & B or A | B
-internal sealed class OperatorExpression
... (truncated)