mirror of
https://github.com/vercel-labs/scriptc.git
synced 2026-11-01 07:33:12 +08:00
Malte Ubl
dea883ff52
Linkers lay out code in input order, and executables linked the program object first, so any change in program size shifted every runtime function. The vendored archives build at -Os, which drops function alignment, so the regex interpreter (lre_exec) landed at a different offset within its cache line after every unrelated edit and swung template-render by up to 17% and regex-logs by up to 8% on x86-64. Executable inputs are now runtime objects, runtime archives, the program object, its partitions, then FFI libraries. Generated code only references runtime-object symbols, so single-pass GNU ld still resolves every archive member; when FFI libraries are present, non-Darwin links list the runtime archives again after them. The native-link-info input order follows the same plan. Vendored archives build with -falign-functions=64 on native targets. On x86-64 the release runtime units do too: generated loops that call runtime helpers otherwise swing by up to 13% with the program's position relative to 16-byte-aligned helpers (numeric-kernels). arm64 keeps its runtime units unaligned, where the size cost is higher and the effect was not measured. A no-op 32-byte growth of the program object moved the baseline by +10.8% (template-render, CI +9.3..+12.9%) and is neutral with this change on every measured workload (Linux, 15 runs).