Optimize empty string pattern matching with null-safe length checks

[Copilot]

String Empty Pattern Match Optimization

This PR optimizes empty string pattern matching to use null-safe .Length == 0 checks instead of string equality comparisons for better performance.

Implementation

The optimization is implemented purely as a code generation optimization in BuildSwitch (PatternMatchCompilation.fs), where Const (String "") patterns are detected and compiled to emit:

1. A null check (brfalse) - skipped if we're in a null-filtered context
2. A length check (callvirt get_Length() followed by comparison with zero)

Key Features

• Pattern discrimination: Empty strings use standard Const (String "") discriminator - no special handling
• Code generation: Optimized null-safe length check instead of String.Equals
• Null-safe context tracking: isNullFiltered parameter tracks when we're in a null-filtered context (after an IsNull test), allowing redundant null checks to be skipped
• No pickle changes: Since we don't use a special discriminator, pickled data remains unchanged and backward compatible
• Pattern matching: All patterns work correctly:
  • | "" -> ... (optimized with null check + length check)
  • | null -> ... | "" -> ... (both cases handled separately)
  • | null | "" -> ... (bundled clauses - single null check from IsNull, then length check without additional null test)

Changes Made

1. BuildSwitch: Added isNullFiltered boolean parameter to track null-safe contexts
2. IsNull/IsInst handling: Sets nullFiltered=true after IsNull test and passes to recursive calls
3. Empty string optimization: Uses .Length == 0 check, conditionally skipping null test when isNullFiltered=true
4. Array length optimization: Also benefits from null-filtered context tracking
5. TypedTreeOps.fsi: Exported mkGetStringLength to support the optimization

Testing

• IL emission test: Verifies optimized IL code generation in TypeTestsInPatternMatching.fs
• Inlining test: EmptyStringPattern.fs with inline functions and --optimize+ flag
  • Basic empty string patterns
  • Patterns with both null and empty string cases
  • Bundled clauses (| null | "" -> ... and | "" | null -> ...)
  • Usage functions demonstrating inlining in action

Generated IL Example

Before (string equality):

IL_0000:  ldarg.0
IL_0001:  ldstr      ""
IL_0006:  call       bool String::Equals(string, string)

After (null-safe length check):

IL_0000:  ldarg.0
IL_0001:  brfalse.s  default_case    // Null check
IL_0003:  ldarg.0
IL_0004:  callvirt   int32 String::get_Length()
IL_0009:  brtrue.s   default_case    // Length != 0 check

The changes are minimal and surgical, affecting only the code generation path for empty string constants without any changes to pattern analysis, type definitions, or data structures.

Original prompt

Motivation

Replace F# pattern match empty string equality with a length check for performance, but preserve null safety. The optimization must ensure that match s with "" pattern NEVER crashes if s is null, even if the programmer did not add a null case.

Implementation Steps

1. Extend DecisionTreeTest with: | StringLengthZero of TType
2. In getDiscrimOfPattern, emit DecisionTreeTest.StringLengthZero for TPat_const (Const.String "").
3. Update discrimsEq and discrimWithinSimultaneousClass to support the new case.
4. In isDiscrimSubsumedBy, ensure null subsumes empty string (avoids emitting a second null check).
5. In BuildSwitch, emit code that guards .Length checks with a null test unless a previous pattern already filtered null. Never access .Length if value might be null.

Testing Steps

• Add/modify tests for typechecking, IL, and runtime under:
  • tests/FSharp.Compiler.ComponentTests/Language/Nullness/NullableReferenceTypesTests.fs
  • tests/FSharp.Compiler.ComponentTests/EmittedIL/PatternMatching/PatternMatchingTests.fs
  • tests/FSharp.Compiler.ComponentTests/Language/Execution/ExecutionTests.fs
• Edge case: Programmer omits "null" pattern, but the value is null.
• Edge case: Both null and "" handled—confirm only one null check is emitted in generated IL.
• Rerun and compare existing IL tests to confirm no regressions or unsafe changes.
• Compile-and-run tests for ("", null, non-empty) must never crash and yield correct output.

Safety

• Never call .Length if the value could be null. Always cover missing null case in tests.

Example Test:

let f (x: string) = match x with | "" -> "empty" | _ -> "other"
// Should not crash for null, must print: "empty,other,other" for ("", null, "x")

This pull request was created from Copilot chat.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[T-Gro]

/run ilverify

[github-actions]

🔧 CLI Command Report

• Command: /run ilverify
• Outcome: success

✅ Patch applied:
- Files changed: 4
- Lines changed: 52

[RealmPlume]

Even with Nullable enabled, pattern matching against "" generates a runtime null check:

let foo2 (x: string) =
    match x with
    | "" -> 0
    | x -> x.Length

The generated IL is:

IL_0000: nop
// if (x != null && x.Length == 0)
IL_0001: ldarg.0
IL_0002: brfalse.s IL_000e

IL_0004: ldarg.0
IL_0005: callvirt instance int32 [System.Runtime]System.String::get_Length()
IL_000a: brtrue.s IL_000e

// return 0;
IL_000c: ldc.i4.0
IL_000d: ret

// return x.Length;
IL_000e: ldarg.0
IL_000f: callvirt instance int32 [System.Runtime]System.String::get_Length()
IL_0014: ret

The emitted IL checks x != null before comparing the string length. Since x is declared as a non-nullable string, this defensive null check seems unnecessary and adds overhead. Is this intentional? Could the compiler elide the null check when nullable reference types are enabled and the input is known to be non-nullable?

[RealmPlume]

Consider the following code:

   let foo2 (x: string) =
      match x with
      | "a" -> 100
      | "" -> 0
      | x -> x.Length

The generated logic is roughly equivalent to:

if (!string.Equals(x, "a"))
{
    if (x != null && x.Length == 0)
        return 0;

    return x.Length;
}
return 100;

I'm not a fan of this transformation. In my opinion, optimizations like this are better left to the JIT/IL optimizer rather than being hardcoded into the pattern-match lowering logic.

A small performance gain may be temporary, but ugly generated code lasts forever. 😄

---

I'm not convinced this optimization is worthwhile. The generated code becomes more complicated and introduces additional null-handling logic, even when nullable reference types are enabled.

I'd rather see the compiler emit simpler and more straightforward IL and let the JIT decide whether further optimizations are profitable.

Performance concerns may change over time as runtimes evolve, but unnecessary complexity in the generated code tends to stay around for a very long time.

[T-Gro]

There is no additional null check - you were just not seeing the null check inside of .Equals prior to this PR.

I am afraid the null check has to be there - nullable reference types are on a best-effort basis. You can have calling code with an older compiler, nullness checking turned off, or simple ignoring (e.g. like C#'s !) nullability.

We are definitely happy to support a contribution that tries to improve this further, happy to discuss options 👍 .
If there is a strong real world use case for pattern matching many constant strings, the compiler could do a shared state machine for the branches.
But as any feature, it would add complexity and has to be well justified.