Make satisfying-sort animation ~3x faster (sort pass only)#318
Conversation
Current Aviator status
This PR was merged manually (without Aviator). Merging manually can negatively impact the performance of the queue. Consider using Aviator next time.
See the real-time status of this PR on the
Aviator webapp.
Use the Aviator Chrome Extension
to see the status of your PR within GitHub.
|
| // Per-step render cost is fixed, so wall-clock speed scales sub-linearly with the | ||
| // derived step delay; SPEED is tuned by measurement (82 => ~9ms/step) rather than | ||
| // picked for a clean fraction. |
There was a problem hiding this comment.
@indent could you remove this comment and make a memory not to leave excessive / train-of-thought comments like this one?
There was a problem hiding this comment.
Done — removed the comment in a97547b, so the diff is now just the one-line SPEED change. The rationale lives in the PR description instead. And noted the preference: I'll keep comments minimal and skip train-of-thought explanations going forward.
…visories Co-Authored-By: Sachin Iyer <siyer@detail.dev>
|
Speeds up the
detail satisfying-sortsort pass by ~3x, leaving the green completion finale untouched.What changed
The sort pass speed is driven by
sort_delay_ms(), which derives a per-step sleep from theSPEEDconstant. The green finale is driven separately byGREEN_SPEED, so it's unaffected. I bumpedSPEEDfrom20to82.Why
82and not a clean "divide by 3": each step also has a fixed render cost, so wall-clock time is not linear in the step delay — dividing the sleep by 3 only got to ~2.36x. I tunedSPEEDby measurement so the step delay lands at ~9ms, which produces a real ~3x end-to-end speedup.Verification (measured in a terminal via PTY)
cargo testpasses (19 satisfying-sort tests), build is warning-free, and a final smoke run of the built binary renders and exits cleanly with no panics.Tag
@indentto continue the conversation here.