Skip to content

Resolve deferred custom logical operators in LightExpression factories - #603

Merged
dadhi merged 3 commits into
dadhi:masterfrom
jogibear9988:fix/direct-logical-factories-standalone
Nov 9, 2026
Merged

dadhi merged 3 commits into
dadhi:masterfrom
jogibear9988:fix/direct-logical-factories-standalone

Conversation

@jogibear9988

Copy link
Copy Markdown
Contributor

Custom AndAlso/OrElse expressions created directly with LightExpression factories can return null from strict compilation because the operator method is deferred. Resolve it through the existing shared operator emitter instead of rejecting the node.

Validation

The focused regression reproduces a failure or crash on master a0950432 and passes with this change. Release solution build passes with zero warnings/errors. Both Standard and LightExpression native suites run.

Runtime TestX passed Legacy passed
.NET 10 361 1,756
.NET 8 361 1,755
.NET Framework 4.7.2 342 1,639

Measurements

Compare master a0950432 with this commit d7616aa5. Windows ARM64, Release; .NET 8.0.28 and 10.0.9. Compilation uses prebuilt trees; invocation uses precompiled delegates and excludes expression construction/compilation. Standard and LightExpression are measured separately.

Two fresh process rounds reverse version-loading order, pin execution to one logical CPU, disable tiered compilation, warm both versions, and alternate measurement order. Values below are medians across 14 samples per side (seven per round; 30 ms calibration target).

Measured compilation and invocation allocations match master on every control. Control delegate IL matches master.

Identical-master control runs also varied: compilation -15.2% to +23.4%, invocation -21.5% to +8.9%. Timings below are observations, not a speedup or universal performance-neutrality claim. Cases that fail or produce invalid IL on master have no meaningful before/after invocation ratio; the table uses executable controls that return the expected result in both versions. Framework correctness is tested above; its performance is not measured here.

All table pairs are master → this change. B/op is allocated bytes per operation.

.NET / API Control Compile ns/op Compile B/op Invoke ns/op Invoke B/op
10 / Light add_control 2,573 → 2,500 872 → 872 1.92 → 1.92 0 → 0
10 / Light boolean_and 2,503 → 2,526 1056 → 1056 1.91 → 1.90 0 → 0
10 / Light custom_and 4,031 → 3,933 1384 → 1384 2.17 → 1.96 0 → 0
10 / Standard add_control 3,109 → 3,095 872 → 872 1.95 → 2.01 0 → 0
10 / Standard boolean_and 3,528 → 3,398 1056 → 1056 1.96 → 1.98 0 → 0
10 / Standard custom_and 5,608 → 5,715 1384 → 1384 2.00 → 2.18 0 → 0
8 / Light add_control 1,022 → 953 872 → 872 1.88 → 1.90 0 → 0
8 / Light boolean_and 946 → 1,072 1056 → 1056 1.90 → 1.90 0 → 0
8 / Light custom_and 1,464 → 1,619 1384 → 1384 2.18 → 2.15 0 → 0
8 / Standard add_control 1,438 → 1,357 872 → 872 2.88 → 2.36 0 → 0
8 / Standard boolean_and 1,370 → 1,078 1056 → 1056 1.94 → 1.92 0 → 0
8 / Standard custom_and 1,619 → 1,729 1384 → 1384 2.25 → 2.18 0 → 0

…tories

Let nonprimitive AndAlso/OrElse nodes use the existing shared operator emitter when factories defer Method lookup. Reuse binary operator discovery for nonlifted nodes while retaining selected methods and existing lifted behavior.
@jogibear9988
jogibear9988 force-pushed the fix/direct-logical-factories-standalone branch from d7616aa to b46e2b4 Compare November 9, 2026 15:04
@dadhi
dadhi merged commit ae893c1 into dadhi:master Nov 9, 2026
4 checks passed
@jogibear9988
jogibear9988 deleted the fix/direct-logical-factories-standalone branch November 9, 2026 21:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants