Issues

• The one-key-per-run! caller has no test and no measurement: per-call costs become per-key costs unnoticed

  chore
  QAtlasHub/SweepRunner.jl#204 · Filter by author sotashimozono opened on Oct 6, 2026

• Warnings raised in a run! called on a worker are echoed nowhere: the stderr echo is gated on myid() == 1

  bug
  QAtlasHub/SweepRunner.jl#203 · Filter by author sotashimozono opened on Oct 6, 2026

• Every run! lists the control requests, observes the sources and rewrites the manifest: per key, for a caller that runs one key per run!

  performance
  QAtlasHub/SweepRunner.jl#202 · Filter by author sotashimozono opened on Oct 6, 2026

• A status file per run!'s master per stage, never removed: the directories accumulate, and every read of "the masters of this run" reads all of them

  performance
  QAtlasHub/SweepRunner.jl#201 · Filter by author sotashimozono opened on Oct 6, 2026

• run! rereads every event file under the outdir at the end of every round: 12 minutes per key for a caller that runs one key per run! in an outdir with 46k event files

  bug
  QAtlasHub/SweepRunner.jl#198 · Filter by author sotashimozono opened on Oct 5, 2026
  3

• Left over from the review rounds of 0.6.9 and the first cluster runs

  chore
  QAtlasHub/SweepRunner.jl#197 · Filter by author sotashimozono opened on Oct 5, 2026

• Structure after two fix rounds: _drive_workers! is 461 lines (was 353), the two loops share less, and a table row can be moved between states from any state

  enhancement
  QAtlasHub/SweepRunner.jl#159 · Filter by author sotashimozono opened on Oct 4, 2026
  1

• Tracking: what a sweep needs to use a large allocation well (speed and efficiency)

  performance
  QAtlasHub/SweepRunner.jl#81 · Filter by author sotashimozono opened on Oct 3, 2026
  3

• No account of where a job's node-hours went: start-up, lock waits, idle slots, the tail and work lost at the end are not measured

  performance
  QAtlasHub/SweepRunner.jl#80 · Filter by author sotashimozono opened on Oct 3, 2026
  2

• Threads per worker are fixed by an environment variable: no choice between time-to-solution and throughput per core, and no measurement to make it with

  performance
  QAtlasHub/SweepRunner.jl#79 · Filter by author sotashimozono opened on Oct 3, 2026
  2

• The master is one process on one core doing everything: relaying all worker output, building shared setup, and shipping the context with every dispatch

  performance
  QAtlasHub/SweepRunner.jl#78 · Filter by author sotashimozono opened on Oct 3, 2026
  2

• State is one small file per key, per segment, per lock, with a heartbeat process rewriting each lock: metadata load that grows with the sweep and with the number of workers

  performance
  QAtlasHub/SweepRunner.jl#76 · Filter by author sotashimozono opened on Oct 3, 2026
  2

• Minutes of every job go to starting Julia: precompile, using on every worker, and building the queue, before any key runs

  performance
  QAtlasHub/SweepRunner.jl#72 · Filter by author sotashimozono opened on Oct 3, 2026
  2

• Worker start-up does not scale: ~100 workers a minute whatever the allocation, and a hard stop near 1800 workers per master on SLURM

  performance
  QAtlasHub/SweepRunner.jl#71 · Filter by author sotashimozono opened on Oct 3, 2026
  2

• Workers are all one size: keys that differ 500x in cost and 6x in memory cannot be packed, so a node runs far fewer keys than it could

  performance
  QAtlasHub/SweepRunner.jl#70 · Filter by author sotashimozono opened on Oct 3, 2026
  3