Repository navigation
Smoother busy rushes; dashboard lists that fit - #380
Merged
Merged
Conversation
Profiled a triple-load rush (the main thread sampled 10 times a second): - Floor plans asked each table's status by rebuilding every open check and the floor, for every table, on every change, inside every command. Now all tables at once, kept until the checks change or the drawing is done; the table widgets watch a change counter (checksRevision) instead of converting the whole open-check list for each table. - Bumping a ticket saved all the settings and told every screen the settings changed (to keep a learned prep time): every screen reloaded its menu and settings on every bump. Prep times are now saved quietly, at most once a minute. - Everyone's tip shares are made once per round of updates, not for every screen; the version history once, not on every update. - A round of updates to the handhelds that took long waits twice that before the next (80 ms to 2 s), so updates never take more than about a third of the store computer's time. At 5x load here: the worst pause 2080 ms -> 558 ms, none over a second (2 before), pauses over 250 ms 60 -> 13; handhelds' slowest 1 in 20 363 ms -> 175 ms. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Weg3awu6SARK7jYrtvDfuw
…ns watch a change counter - jsonText writes the screens' updates (maps, lists, text, numbers) straight from the data instead of through QJsonValue and QJsonDocument; anything unusual still goes Qt's way. A test checks it reads back as Qt's for every kind of value. - Table, table grid, floor plan and waitlist widgets watch checksRevision instead of reading the whole openChecks list (converted for every table) just to know when to ask again. At 5x load here: the worst pause 558 -> 193 ms (2080 at the start), pauses over 100 ms 152 -> 38, none over 250 ms; handhelds' slowest 1 in 20 175 -> 98 ms, worst 1146 -> 353 ms. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Weg3awu6SARK7jYrtvDfuw
… checks Profiled on the AIO (a Pi): building the kitchen's and the expediter's tickets was the biggest cost in a rush, because both looked through every line of every check closed today, again on every change. A busy night closes a thousand. - PosShared remembers closed checks with nothing left for the kitchen (kitchenDone) or the expediter (expoDone) and skips them. Done stays done: bumping and running only take items off. A recalled ticket, a check closed again after a reopen, a menu or settings change (what goes where) and End of Day forget them. - The split-check widget watches checksRevision instead of reading the whole open-check list. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Weg3awu6SARK7jYrtvDfuw
…store computer The stress test ran 13 of its pretend staff (bartenders, hosts, cashiers, expo, bussers...) on the store computer's own main thread, each with a "screen" there, as if a dozen people shared one computer. In a store each of them is at a screen or handheld of their own. Now only the manager (the office: reports, deliveries) is at the store computer; everyone else connects over the network, so what they ask is still the store computer's work, and what their own screens do with the answers isn't. The report counts the people on screens and handhelds of their own (not connections) and says "over the network" for their timings. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Weg3awu6SARK7jYrtvDfuw
About a third of the demo's card payments are keyed in (no last four). Just after the business day starts there are only a few, and all of them can be keyed in (it failed in UTC after midnight: 3 of 3). Check that some card payment names its card once there are at least ten. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Weg3awu6SARK7jYrtvDfuw
On a busy day the On the clock list (and best sellers, running low) grew past its card and names ran off the bottom of the screen. Each list now scrolls inside its card, with a scroll bar beside it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Weg3awu6SARK7jYrtvDfuw
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.
Smoother busy rushes, and dashboard lists that fit
The main thread was profiled during the stress test's triple-load rush, here and on the store computer (a Raspberry Pi CM5). This fixes what it found.
Speed
checksRevision) instead of converting the whole open-check list for each table.Results
The Pi results above come from the old stress setup, which ran 13 people's screens on the store computer itself. A Pi run with the realistic setup below hasn't been done yet.
Tests
Fix
556 tests pass, and the same suite passes on Qt 6.8, the Pi's version, apart from the version-history check, which can't run without the git history.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Weg3awu6SARK7jYrtvDfuw