Is there way to disable amortized constraints check?

[lekrus]

The optimization was introduced in #2672
If there is a loop of slow actions they will bypass time constraints.
If we know for sure that engine is run in slow contexts it would help to be able to disable the optimization.

using (var cts = new CancellationTokenSource()) {
	var engine = new Engine(o => o.CancellationToken(cts.Token));
	engine.SetValue("sleep", (Action<int>)(ms => Thread.Sleep(ms)));
	cts.CancelAfter(TimeSpan.FromMilliseconds(200));
	var sw = Stopwatch.StartNew();
	Action few = () => engine.Execute("for (let i = 0; i < 40; i++) { sleep(100); }"); // ~4s
	few.Should().NotThrow("4.13.0 amortization skips the token check for a 40-iteration loop");
	sw.Stop();
	sw.ElapsedMilliseconds.Should().BeGreaterThan(3000, "so the loop runs to completion (~4s) despite the cancel");
}

[lahma]

Thanks for the report — this was a real gap in the #2672 amortization, and it's fixed in #2713 plus the hardening follow-ups #2714/#2715 (will be in the next release).

Rather than adding an option to disable or tune the amortization, the amortization itself was fixed. It bounded timeout/cancellation detection latency in statement count (64 statements), which is only a valid proxy for wall-clock time while statements stay cheap — and a statement that calls into host code can take arbitrarily long, exactly as in your repro. The engine now re-checks the time/cancellation constraints whenever control returns from host code to the interpreter (delegates registered via SetValue, wrapped methods/properties/fields/indexers, dictionary-backed and enumerable interop, CLR constructors and operator overloads — including async continuations driven from the host). Detection latency is bounded by a single host call again, like it was before 4.13.0, while cheap pure-JS statements keep the amortized fast path — so there's no knob to configure and nothing to trade off.

Your example now throws ExecutionCanceledException after ~290 ms (the 200 ms cancel plus the in-flight 100 ms sleep whose return observes it) instead of running the loop to completion, and there's a regression test with exactly your loop shape.

One caveat: if you host long-running CLR code behind a hand-built ClrFunction (the raw JsCallDelegate wrapper, which is also what all engine built-ins use), that fast lane is intentionally not instrumented — observe the CancellationToken in your own code there. All the normal SetValue(delegate/object) interop paths are covered.

[lekrus]

Thanks!