Repository navigation
Conversation
…ently and state what each run says Each `bun test --aot` run of the file is a test of its own, as in #47605, and the five are `test.concurrent`: `--max-concurrency` says how many build at once. A debug build keeps them one after another. Plain Bun must give a stated report: every printed line, the result of each test file, the counts and the exit code. Each compiled run must give the same report and name its form.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 8 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. CodeRabbit Verify
|
|
Status: ready for review. This is a test-only change to Build #137270 has ended red for 29 other test files. None is this file, and this diff touches none of them.
How this was checked, on Linux x64:
The CI times above are for the file in a process of its own, which is how CI runs a file that a PR changes. On main the file runs in a batch with two builds at once. The PR body has the local measure for that. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
Problem
test/aot/a-module-whose-link-fails-imports-what-other-files-import.test.tstakes 291 s on debian 13 x64-asan (build #137158), 67 s on x64, 48 s on aarch64.bun test --aotruns go one after another, and each compiles about 3,800 library functions.--aotpasses two of three tests.Fix
bun test --aotfollows #44833's mocks #47605, andtest.concurrent. A debug build keeps them serial.bun bd test: 250 s and 237 s.Background
Notes
What stays as it was. Both projects are the same text. The commands are the same nine: four plain runs and five compiled runs, with the same flags. The two compiled runs that had no word now have
TestRunSaysItsForm. That word makes a run print its form and changes nothing else (log_form_of_test_runinsrc/runtime/cli/run_compiled.rs).run()ofharness/run.tsstill fails the run in layers if it was not built in two layers.Assertions, before and after.
toMatchObjecttoEqual, for both plain runstoContain, for three of the four plain runs2 pass,4 fail,4 errors,Ran 6 tests across 6 files.)expectLayers)one program | test files N, orlayers 2 | test files 6 | to a program 1toEqualof what was readtoEqualof what is read nowexpect()calls: 12 before, 10 after. OnetoEqualholds what several held.Two faults that only the new file finds. I put each into both versions of the file and ran them with the release build.
--aotsrc/imports-absent.mjsimportsone, which is there. Its test file passes and printsnever printedThe first:
The second, in both "what plain Bun says" tests:
Where the time goes. Release build, 12 processors, each command alone:
With
BUN_JSC_logAOTPhaseTimes=1each compiled run says that it compiles 127 to 137 units and 3,749 to 4,004 functions. A project with one passing test file compiles 57 units and 173 functions in 0.8 s of processor time. The same project with a second test file that imports a module whose link fails compiles 128 units and 3,783 functions in 9.7 s. So the cost comes with the subject of the file. With the debug build one compiled run takes 216 to 293 s of processor time. A compiled run holds 0.2 to 0.3 GB at its peak with the release build and 1.1 GB with release-asan, so five at once hold 5.6 GB there.Why five builds.
import()reaches the module whose link fails.All local runs. Linux x64, 12 vCPUs, 15.6 GB,
tasksetfor fewer processors. Before and after ran in turn.The file alone:
bun bd testbun-profilebun-profile--max-concurrency=2. 14.2, 14.3 s with=4scripts/runner.node.tsUser time of those rows: debug 1479, 1401 s before and 1362, 1401, 1420 s after. Release on 12 processors 54 s before and 56 s after. Release-asan 238, 231, 242 s before and 261, 249, 249 s after. One build keeps about four processors busy, so on 4 processors two builds at once end little sooner than one after the other.
The file in a batch, started as
runParallelBucketofscripts/runner.node.tsstarts one (bun test --parallel=<n> --max-concurrency=2):--parallel=7, this file and six long files--parallel=3, the same seven files--parallel=3, this file and seven shorter filesa-mocked-commonjs-file-keeps-its-own-exports,a-module-that-a-test-writes-imports-compiled-files,a-module-that-exists-only-as-a-mock-is-found-wherever-mock-comes-from,a-name-imported-from-a-built-in-module-keeps-what-the-module-had-at-the-link,a-name-that-two-stars-export-is-ambiguous-to-code-from-disk,a-package-that-loads-one-of-two-files-by-node-env-in-a-test-run. Each takes 17 to 68 s in the release batch.CI. The file passed on its first try on each of its three lanes.
The two columns are not the same way of running the file. On main the file is in a batch:
--parallel=7 --max-concurrency=2on x64-asan, so two of its builds run at once. A file that a PR changes runs in a process of its own with--max-concurrency=min(20, processors): here all five builds at once beside two other files on x64-asan, and four at once beside one other file on x64 and aarch64. For the batch on main, the local rows "in a batch" above are the measure.Five builds at once take processors from the files beside them. On x64-asan
code-the-compiler-never-saw.test.tsran beside this file and took 120 s. Its median on that lane is 75 s (test/expected-durations.json). It passed.Limits. A test has the default of
test/aot/supported.ts: 120 s, and 270 s with a sanitizer or a debug build. The longest test took 80.5 s in the release-asan batch, 11.4 s in the release batches, and 55.5 s with the debug build.Why a debug build keeps the runs one after another. Five at once with the debug build took 154 s on 12 processors (a test took 144 to 150 s), 196 s on 8 (184 to 193 s) and 242 s on 6 (226 to 240 s). A test has 270 s there. One after another a test takes 38 to 56 s. The file says
test.serialand nottest: in #47605testofsupported.tsis concurrent with a sanitizer, and a debug build has one.#47605. That PR splits the first test in the same way: a
beforeAllfor the two plain runs, two tests for what plain Bun says, one test for each compiled run, no explicit limits. This PR takes that shape and its titles, so one rebases onto the other without a change of structure. On top of #47605 this PR addstest.concurrentwhere no sanitizer is, the stated reports and the form. #47605 importsafterAllfromharness/default-timeout. Main does not export it there yet, so here it comes frombun:test.Not taken.
bun test --aotmakes.toMatchInlineSnapshotof stdout and stderr: a compiled run prints its form first, and withBUN_JSC_logAOTPhaseTimesin the environment thousands of lines more. The reports are data that seven tests share.Not run. CI runs this file on the three Debian lanes only (
runsOnThisLaneinscripts/runner.node.ts). I ran it on Linux x64 only. The patterns for the form accept the line of a Bun that loads one program a realm (macOS, Windows). I read that line inlog_form_of_test_runand did not run it.[auto-merge] gate passed · iteration 0 · 1 files touched
passes on PR (with fix)
diff hotspot
gate history · 1 passed · 0 rejected · iteration 0
evidence per changed file