Strings: a long + defers its copy, so s = s + x is linear like s += x

[lahma]

s += x and s = s + x mean the same thing and did not cost the same thing. The compound form builds into JsString.ConcatenatedString, which is StringBuilder-backed and amortised linear; a plain + went through ApplyAdditionToPrimitives, which coerced both operands to string and returned JsString.Create(string.Concat(left, right)), so every iteration of an accumulator loop copied the whole left operand. Prepending (s = x + s) had no fast path at all, because += cannot express it.

Fixes #3350.

The node

+ cannot simply reuse ConcatenatedString: it is mutated in place, and += may do that only because the assignment replaces the receiver. A non-assignment + leaves both operands reachable from wherever they were read, so the deferred form it can use has to be immutable — which is also the property that makes it work for prepend, the shape += can never reach. JsString.RopeString (internal, nested beside ConcatenatedString and SlicedString) is that form: two JsString operands and a total length.

JsString.Concat builds one once the result reaches 512 characters and concatenates flat below that. The threshold is a knob for the small-string case, not for the fix: a loop accumulating in n-character pieces copies for the first 512/n iterations and defers from then on, so the entire quadratic term is bounded by 512² characters however long the loop runs.

The five things that are ways to get this wrong:

Hazard	How it is handled
Length without flattening; ToString() flattening once	Length is a stored field, so str.length, truthiness and the length comparison Equals(JsString) performs first are all free. ToString() is _value ?? Flatten(), and Flatten memoizes into _value and releases both child references, so a flattened value stops retaining the tree it was built from — one node per iteration, for an accumulator loop.
Equality and GetHashCode consistent with the flat forms	Not overridden, deliberately. The base bodies read _value only when it is either null or the exact flat text, which is precisely the invariant this class keeps (the one ConcatenatedString does not, which is why it has to override them). Pinned both before and after flattening, and as a Map/Set/property key on both sides of a lookup.
Members that do not route through ToString()	Length and this[int] are the only two the class declares. this[int] flattens rather than descending: descending is O(depth), so a charCodeAt scan over a freshly accumulated value would be a new quadratic — the very shape being removed. Flattening costs the one copy the old code performed on every concatenation anyway, and the memo makes every later read O(1). Contains, IndexOf, StartsWith, EndsWith, Substring, Equals(string), TryGetIterator, Append, EnsureCapacity and ToObject all route through ToString() already and are correct unchanged.
A depth bound	There is no cap on construction, and that is the design. Flushing at a depth bound re-copies the whole accumulator every N operations — the quadratic again, with a smaller constant, i.e. the thing being fixed. The hazard a cap would have addressed (a recursive flatten overflowing the CLR stack on the unbalanced tree a long loop produces) is removed at its source: the flatten walk is iterative over an explicit heap array, so depth costs 8 bytes per pending node against the ~40 the node already costs, and no stack frames at all. It descends right-first, so the append shape (s = s + x, a left-leaning spine) never holds more than one pending entry; the prepend shape is the one that pays for the array. Tested at 200,000 nodes in both leanings.
MaxLength enforcement	Unchanged in position: the check is on the summed operand lengths, before the result is built — now before rather than after a large operand is materialized. That check is also what lets the node's int length arithmetic be unchecked.

One more hazard the issue did not name, and the reason Immutable exists: an operand may itself be a ConcatenatedString, which a later += grows in place. A node that merely held the reference would change content behind whoever read the concatenation, so such an operand is snapshotted on the way in — a wrapper around the string the builder has already flattened, not a character copy. AppendingToAnOperandAfterwardsDoesNotChangeTheResult pins it.

The flattened a + b + c chain (AdditionChainExpression) gets the same decision, through three helpers shared by the direct and the resumed paths, so s = s + a + b is linear too — otherwise it would have been the one shape that stayed quadratic. Below the threshold it still concatenates in the single allocation that node exists to produce, and the coercion moved from TypeConverter.ToString to TypeConverter.ToJsString, which produces the same characters without materializing an operand's representation.

+= is untouched. Not one line of JintAssignmentExpression changed, and Append/EnsureCapacity are not overridden on the node — a += against a deferred value flattens once and lands back on the builder lane, which is what keeps repeated small appends on the representation that is best for them.

Evidence

Asymptotics, measured by allocation rather than wall-clock — the quadratic is the copying, so allocated bytes say the same thing as a stopwatch without depending on what else the machine is doing. AccumulatingWithPlusIsNoLongerQuadratic builds at 4,000 and 8,000 iterations of a 10-character chunk and asserts the ratio is under 3 (linear ≈ 2, quadratic ≈ 4) plus an absolute 16 MB ceiling. Measured on this branch against the same test with the deferral threshold set to int.MaxValue, which is exactly the old behaviour:

shape	8,000 iterations, before	after
s = s + x	640,600,272 B	478,848 B
s = x + s	640,805,928 B	478,848 B
s = s + x + y	1,280,612,824 B	913,448 B

Every other new test also fails against that same disabled-threshold build, so none of them is asserting a tautology.

Jint.Repl, Release, the issue's own repro (indicative only — REPL timings, not gate-quality numbers): s = s + x went 463 ms → 10 ms at 20,000 iterations and 1,626 ms → 20 ms at 40,000, i.e. from 3.5× for 2× the work to 2.0×. s = x + s and s = s + x + y scale the same way.

A side effect worth its own row: s = s + s now doubles the length by referencing the same value twice, so the MaxLength guard for + is reachable through 29 nodes and no characters at all. That path used to need the half gigabyte it exists to prevent, and StringLengthLimitTests said so in prose; it now has a real test.

Benchmarks — added, not run

Four lanes in StringConcatLargeBenchmark, which had none of this shape (every accumulating lane there uses s += chunk, and ConcatLargePair rebuilds a fresh pair each iteration so its left operand never grows — which is why the July 2026 rope evaluation came out a NO-GO for what it measured):

• AssignAppendSmallChunks — s = s + chunk16 × 4,096
• AssignPrependSmallChunks — s = chunk16 + s × 4,096
• AssignChainThree — s = s + chunk16 + chunk16 × 2,048
• AssignAppendThenScan — the first one plus a charCodeAt scan of the result

Measurement is outstanding. This machine runs agents concurrently, so nothing here was benchmarked and no timing figure in this PR comes from BenchmarkDotNet. JINT_BENCH_MODE=gate on an idle machine, run serially, paired against main:

JINT_BENCH_MODE=gate dotnet run -c Release --project Jint.Benchmark -- --filter "*StringConcatLargeBenchmark*"

The pairings that carry the reading:

1. AssignAppendSmallChunks vs AppendSmallChunks — the same 4,096 × 16 characters with one operator changed. This is the headline: the difference between them is the whole remaining cost of the + path.
2. AssignAppendThenScan vs AssignAppendSmallChunks — the same build plus a read-back, so their difference is what flattening costs. The other three lanes finish on s.length, which a deferred value answers without ever producing characters, so this is the one a deferred representation cannot cheat.
3. ChainSmallThree and ChainSmallSix, branch vs main — the guard rows. Short chains take the flat path and must not get slower; the only change they see is that the operand lengths are now read through a virtual Length rather than off the coerced string.
4. AppendSmallChunks, AppendLargeChunks, BuildLargeThenScan, branch vs main — the += rows. They must be flat: no code on their path changed, but they now share JsString.Length / ToString() call sites with one more subclass, and a lost guarded devirtualization would show up here or nowhere.
5. ConcatLargePair and ChainLargeThree should improve outright (big64k + big64k followed by .length no longer copies 128 KB); they are the least interesting rows here.

Verification

• dotnet build -c Release — clean, 0 warnings, all five target frameworks.
• Jint.Tests — 10,745 passed on net10.0 and net8.0, 7,369 on net472 (which is what exercises the #if NETFRAMEWORK half of the flatten), 0 failed. Also green with JINT_HOST_CONTRACT_VERIFICATION=1.
• Jint.Tests.PublicInterface — 2,998 passed on net10.0, 2,369 on net472, 0 failed. No public API added, so UndocumentedPublicApi.txt (634) is untouched; RopeString is internal and nested, like its two siblings.
• Jint.Tests.CommonScripts — 28/28 on both frameworks.
• Jint.Tests.Test262 — 102,495 passed, 0 failed, 189 skipped. Unchanged.

Documentation

• docs/v5-migration.md §4.27 — a + may now hand a host a JsString subclass (it always could, for +=, so only an exact-type test is affected), and the result keeps its operands alive until something reads its text.
• README.md — the LazyJsString section listed concatenation among the operations that materialize a lazy host string. A long one no longer does; it holds the value as an operand.
• Jint.Benchmark/StringConcatLargeBenchmark.cs, Jint.Tests/Runtime/StringRepresentationKeyTests.cs and Jint.Tests/Runtime/StringLengthLimitTests.cs all carried prose that this change makes wrong; each is corrected in place rather than left to mislead the next reader.

Nothing dropped

One judgement call worth flagging for review: Flatten() carries a #if NETFRAMEWORK || NETSTANDARD2_0 block rather than a Polyfills.cs entry, against the repository's polyfill-downwards rule. What those targets lack is not string.Create but System.Buffers.SpanAction<T, TArg>, its callback type — a "polyfill" declaring a delegate of its own would be inventing API rather than backfilling it. The downlevel arm fills a char[] and copies it into the string; the modern arm writes the characters into the string as it is allocated, and that single copy is what keeps a flattened concatenation no more expensive than the string.Concat it replaced.