[Performance] Vectorize string.StartsWith for static readonly strings by reedz · Pull Request #123755 · dotnet/runtime

reedz · 2026-01-29T15:01:53Z

Related work/discussions: #84524, #48160, #61733.

Existing vectorization deals with literals, but not static read-only string fields. Following how VN-based intrinsic expansion is done for in fgVNBasedIntrinsicExpansionForCall_ReadUtf8, I'm adding fgVNBasedIntrinsicExpansionForCall_StringComparison that vectorizes cases as shown in #84525:

private static readonly string s_prefix = "/api/data";

...
str.StartsWith(s_prefix, StringComparison.Ordinal)

I have quick and dirty benchmarks suggesting that string.StartsWith(s_readonlyFieldString) have been significantly sped up, but I'd rely on bots to prove me right or wrong.

Copilot

Pull request overview

This pull request adds Value Numbering (VN)-based intrinsic expansion for String.StartsWith to vectorize cases where the comparison string is a frozen/immutable string from a static readonly field. The existing import-time vectorization only handles string literals, but this enhancement allows vectorization when the JIT can prove through VN that a string argument points to a frozen object.

Changes:

Adds VN-based expansion logic to detect and vectorize StartsWith calls with frozen strings
Marks StartsWith as a special intrinsic even when import-time vectorization fails, allowing later VN-based optimization
Extends the special intrinsic framework to handle NI_System_String_StartsWith alongside the existing ReadUtf8 expansion

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/morph.cpp	Adds `NI_System_String_StartsWith` to the special intrinsic check alongside `ReadUtf8`
src/coreclr/jit/importercalls.cpp	Marks `StartsWith` as special intrinsic even when import-time vectorization fails
src/coreclr/jit/helperexpansion.cpp	Implements `fgVNBasedIntrinsicExpansionForCall_StringComparison` to expand `StartsWith` with frozen strings
src/coreclr/jit/compiler.h	Adds function declaration for the new string comparison expansion

Copilot · 2026-01-29T15:09:00Z

src/coreclr/jit/helperexpansion.cpp

+        JITDUMP("StringComparison: string exceeds max buffer size\n")
+        return false;
+    }
+


The variable strObjOffset retrieved from GetObjectHandleAndOffset is not validated or used. For a string object reference (the expected case), this offset should be 0. However, unlike the similar fgVNBasedIntrinsicExpansionForCall_ReadUtf8 function which validates strObjOffset <= INT_MAX, this function doesn't validate the offset value. Consider adding a check such as if (strObjOffset != 0) { JITDUMP(...); return false; } to ensure the VN represents a direct string object reference and not some other pointer pattern.

Suggested change

if (strObjOffset != 0)

{

JITDUMP("StringComparison: unexpected string object offset %d\n", (int)strObjOffset)

return false;

}

Copilot · 2026-01-29T15:09:00Z

src/coreclr/jit/helperexpansion.cpp

+    StringComparison cmpMode = Ordinal;
+    if (argCount == 3)
+    {
+        GenTree* comparisonArg = call->gtArgs.GetUserArgByIndex(2)->GetNode();
+        if (!comparisonArg->IsIntegralConst())
+        {
+            JITDUMP("StringComparison: comparison type is not constant\n")
+            return false;
+        }
+
+        ssize_t cmpValue = comparisonArg->AsIntCon()->IconValue();
+        if (cmpValue == Ordinal)
+        {
+            cmpMode = Ordinal;
+        }
+        else if (cmpValue == OrdinalIgnoreCase)
+        {
+            cmpMode = OrdinalIgnoreCase;
+        }
+        else
+        {
+            JITDUMP("StringComparison: unsupported comparison type %zd\n", cmpValue)
+            return false;
+        }
+    }


When argCount == 2, this corresponds to the StartsWith(string value) overload which uses StringComparison.CurrentCulture semantics (not Ordinal). The code defaults to Ordinal mode, which is incorrect for this overload. While this overload should normally be inlined (converting it to a 3-arg call with CurrentCulture), if inlining fails, the optimization would proceed with incorrect semantics. Consider adding an explicit check: if (argCount == 2) { JITDUMP("2-arg StartsWith uses CurrentCulture, cannot vectorize\n"); return false; }.

EgorBo · 2026-01-29T17:18:35Z

I think the pattern in question is already handled by #121985 ?

reedz · 2026-01-30T08:56:41Z

I think the pattern in question is already handled by #121985 ?

@EgorBo perhaps we could craft some benchmarks to verify ? IIUC #121985 doesn't handle the case when one of the operands is runtime value.

EgorBo · 2026-02-02T20:53:13Z

I think the pattern in question is already handled by #121985 ?

IIUC #121985 doesn't handle the case when one of the operands is runtime value.

Ah right.

private static readonly string s_prefix = "/api/data";

static bool Test(string str) => str.StartsWith(s_prefix, StringComparison.Ordinal);

I see that we unroll this case even today, because StartsWith is inlined into SpanHelpers.SequenceEqual so for the constant length (static readonly string is folded into a frozen object too) we properly unroll it in Lower, just a little bit less efficient.

This logic effectively duplicates importervectorization.cpp which is fine if we actually delete importervectorization.cpp and move it here. Unfortunately, it seems to be focusing only on StartsWith and assume it will never inline.

Do you have a benchmark for this?

reedz · 2026-02-08T12:57:03Z

@EgorBo upon closer inspection it seems it makes more sense to move frozen object handling logic to importer vectorization rather than handling individual cases as was done previously - I've updated the PR with this change.

The benchmarks seem to be showing ~50% performance improvement for the following:

using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

BenchmarkSwitcher.FromAssembly(typeof(StartsWithBenchmark).Assembly).Run(args);

[MemoryDiagnoser]
public class StartsWithBenchmark
{
    private static readonly string s_shortPrefix = "/api";
    private static readonly string s_mediumPrefix = "/api/data/v1";
    private static readonly string s_longPrefix = "/api/data/v1/users/profile";

    private string _matchingShort = default!;
    private string _matchingMedium = default!;
    private string _matchingLong = default!;
    private string _nonMatching = default!;

    [GlobalSetup]
    public void Setup()
    {
        _matchingShort = "/api/users/123";
        _matchingMedium = "/api/data/v1/items/456";
        _matchingLong = "/api/data/v1/users/profile/settings";
        _nonMatching = "/home/index.html";
    }

    [Benchmark]
    [MethodImpl(MethodImplOptions.NoInlining)]
    public bool Short_Match() =>
        _matchingShort.StartsWith(s_shortPrefix, StringComparison.Ordinal);

    [Benchmark]
    [MethodImpl(MethodImplOptions.NoInlining)]
    public bool Medium_Match() =>
        _matchingMedium.StartsWith(s_mediumPrefix, StringComparison.Ordinal);

    [Benchmark]
    [MethodImpl(MethodImplOptions.NoInlining)]
    public bool Long_Match() =>
        _matchingLong.StartsWith(s_longPrefix, StringComparison.Ordinal);

    [Benchmark]
    [MethodImpl(MethodImplOptions.NoInlining)]
    public bool Short_NoMatch() =>
        _nonMatching.StartsWith(s_shortPrefix, StringComparison.Ordinal);
}

EgorBo · 2026-02-20T14:58:10Z

The PR doesn't handle the same case for Span.
I'm just curious, is it a some kind of AI tool driven contribution?

EgorBo · 2026-02-20T14:59:20Z

src/coreclr/jit/importervectorization.cpp

+            {
+                return nullptr;
+            }
+            if (!info.compCompHnd->getObjectContent(objHnd, (uint8_t*)str, (int)(cnsLength * sizeof(char16_t)),


the code seems to have an assumption that the field is a string. I don't see how that assumption is validated

EgorBo · 2026-02-20T15:00:12Z

src/coreclr/jit/importervectorization.cpp

+
+    auto isFrozenObjHandle = [](GenTree* node) -> bool {
+        return node->IsIconHandle(GTF_ICON_OBJ_HDL) && node->TypeIs(TYP_REF);
+    };


this looks like an unnecessary use use of a lambda. node->TypeIs(TYP_REF) is redundant. GTF_ICON_OBJ_HDL implies it's a frozen object

vectorize string.StartsWith for static readonly strings

28af1c9

Copilot AI review requested due to automatic review settings January 29, 2026 15:01

github-actions bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 29, 2026

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Jan 29, 2026

Copilot started reviewing on behalf of reedz January 29, 2026 15:02 View session

Copilot AI reviewed Jan 29, 2026

View reviewed changes

address review feedback

a34694b

EgorBo reviewed Feb 20, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments

[Performance] Vectorize string.StartsWith for static readonly strings#123755

[Performance] Vectorize string.StartsWith for static readonly strings#123755
reedz wants to merge 2 commits intodotnet:mainfrom
reedz:feature/fold-path-string-pattern

reedz commented Jan 29, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 29, 2026

Uh oh!

Copilot AI Jan 29, 2026

Uh oh!

EgorBo commented Jan 29, 2026 •

edited

Loading

Uh oh!

reedz commented Jan 30, 2026

Uh oh!

EgorBo commented Feb 2, 2026

Uh oh!

reedz commented Feb 8, 2026

Uh oh!

EgorBo commented Feb 20, 2026

Uh oh!

EgorBo Feb 20, 2026

Uh oh!

EgorBo Feb 20, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

+    if (strObjOffset != 0)
+    {
+        JITDUMP("StringComparison: unexpected string object offset %d\n", (int)strObjOffset)
+        return false;
+    }

Comments

Conversation

reedz commented Jan 29, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

EgorBo commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

reedz commented Jan 30, 2026

Uh oh!

EgorBo commented Feb 2, 2026

Uh oh!

reedz commented Feb 8, 2026

Uh oh!

EgorBo commented Feb 20, 2026

Uh oh!

EgorBo Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

EgorBo Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

EgorBo commented Jan 29, 2026 •

edited

Loading

EgorBo Feb 20, 2026 •

edited

Loading