Follow-up from #33 / run https://github.com/zig-utils/zig-js/actions/runs/29172632725.
The new threads-test timing summary showed that the serialized/GIL corpus long pole is no longer just an unlucky shard mix: one case is pathological by itself.
Evidence
threads-gil (shard 1/4) on commit 27bd8150d271d5b21ac168babcf0db618e91e281:
- total shard elapsed:
3,166,165 ms(~52.8 min) - slowest case:
dw1-sort-comparator-callsite-shapes.jsat2,543,010 ms(~42.4 min) - next slowest case:
jit/tid-tag-3-threads.jsat252,632 ms(~4.2 min)
The weighted shard fix in 515fcb918f7cbd0ba01af14f54f0f1b0dd55d750 isolates the 42-minute case so it no longer piles up with other heavyweight cases, but it does not solve the underlying runtime cost.
Goal
Understand and reduce the serialized/GIL runtime of dw1-sort-comparator-callsite-shapes.js without weakening the PR-249 corpus semantics.
Sketch
- Run the case under a profiler or add focused counters around sort comparator callsites / iterator host paths.
- Compare with the sibling
dw1-sort-comparator-iterator-host.jsanddw1-sort-comparator-osr.jstimings. - Decide whether this is an engine performance issue, pathological test workload that needs a dedicated CI profile, or a missing fast path.
Acceptance criteria
- The case has a focused profile explaining where the ~42 minutes go.
- Either the runtime is materially reduced, or CI documents/runs it as an intentionally isolated heavyweight conformance leg.
- The full serialized threads corpus remains semantically covered.