Repository navigation
fix(hotblocks): give each shadow run its own thread - #120
Merged
Merged
Conversation
A shadow thread that waits for a run's parallel work runs other jobs of its pool meanwhile, and in the shared shadow pool those jobs are whole other runs, so one run's time could hold several. Runs now go to single-thread workers, as query tasks do with a thread per task. Runs where the legacy engine is the slow one are counted too: the slow-run count alone cannot tell a slow engine from a slow host. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The shadow's slow-run count makes the new engine look slower than it is, for two reasons.
joinfor a run's parallel work, rayon gives it any other job of the pool, and in this pool every job is a whole run. The waiting run's time then includes the other run. Both engines use rayon on the current pool, and the legacy engine's polars steps wait the same way.The slow-run log of one busy dataset shows both effects. Its runs on a one-block chunk took the new engine 76 ms at the median and the legacy one 2 ms. Neither engine spends 76 ms on one block, and over all runs the new engine's time tail is lighter than the legacy one's.
Change
--shadow-max-in-flightsingle-thread workers, theTaskQueuethat query tasks use with--query-thread-per-task. A run'spar_iterandjoinstay on its thread, and no run waits for another. The number of shadow threads does not change.hotblocks_shadow_legacy_slow_runs_totalcounts the runs where the legacy engine is slow by the same rule, so that the two counts can be compared. Only runs where the new engine is slow are logged, as before.Trade-off
A run's rayon work now runs on one thread for both engines; the legacy engine's polars steps stay on the shared pool. A heavy run takes longer than before, when idle shadow threads could help it, and the same as it would with a thread per task. Slow-run counts from before and after this change do not compare.
Tests
a_run_never_runs_another_inside_its_time: a run waits injoinwhile a second run is queued. It fails on the old shared pool 10 times in 10, and passes 20 times in 20.either_engine_can_be_the_slowerchecks the rule in both directions, under the margin and under the ratio.shadow_engineandquery_task_metricspass, and clippy reports nothing new.🤖 Generated with Claude Code