From 9622e957cdd9602a2f2230ed7d4c90b06688a217 Mon Sep 17 00:00:00 2001 From: blasty Date: Thu, 6 Aug 2026 23:25:23 +0200 Subject: tests: wait for the thing, don't sleep and hope test_trace_ui spent 18.8 of its 35.2 seconds in flat pilot.pause() calls placed to let an async seek land. Two loops were most of it: 6 iterations at 0.5s and 28 at 0.3s, 11.4s of sleeping to check that a step moves the cursor. They are condition waits now. The questions are unchanged -- does the listing cursor reach the pc, does the pseudocode cursor follow -- but they cost what they cost instead of a fixed budget. The second loop settles on something that does NOT presuppose the answer (the listing cursor arriving, and the trail map belonging to the loaded function): waiting on 'is this pc mapped' would have burned the timeout on every unmapped instruction, about half of them, and come out slower than the sleep it replaced. 35.2s -> 20.9s, 39 checks, stable over repeated runs. tests/_fixtures.py collects the staging both this suite and test_scenarios need -- scratch copy, seeded from a golden .i64 nothing writes back to -- which was private to test_scenarios. Worth saying plainly: on targets/echo the seeding is worth 0.19s, not the analysis time I assumed when I went looking. It is shared for the deduplication and for whatever gets pointed at a bigger binary. --- tests/run.py | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'tests/run.py') diff --git a/tests/run.py b/tests/run.py index ca0a319..4920e54 100755 --- a/tests/run.py +++ b/tests/run.py @@ -20,6 +20,14 @@ first time someone adds a test, **each test file declares it**:: modules run their suite at import time). A test file with no marker is a hard error, so a new test can't quietly join the fast set and start needing IDA. +Deliberately **serial**. Running the IDA suites concurrently looks like the +obvious win (they are independent processes with their own worker and temp dir, +on a 12-core box) and it is measurably a loss: 4 at a time took the suite from +153s to 296s and killed three of them with broken-pipe worker failures -- +thumb_ui alone went 10.4s to 287.8s. idalib contends hard enough that the extra +processes only starve each other, and a starved worker gets reaped mid-analysis, +which reads as a flaky test rather than as load. Don't re-add --jobs. + Usage:: python3 tests/run.py # everything -- cgit v1.3.1-sl0p