Skip to content

Smoother busy rushes; dashboard lists that fit - #380

Merged
No0ne558 merged 6 commits into
ViewTouch:mainfrom
No0ne558:Modernization
Oct 15, 2026
Merged

No0ne558 merged 6 commits into
ViewTouch:mainfrom
No0ne558:Modernization

Conversation

@No0ne558

Copy link
Copy Markdown
Contributor

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

  • Floor plans: each table's status used to rebuild every open check and the floor plan, for every table, on every change. Now all tables are worked out at once, and the table widgets watch a change counter (checksRevision) instead of converting the whole open-check list for each table.
  • Kitchen and expo screens: these looked through every check closed that day, on every change. They now skip closed checks with nothing left to make or run. A recalled ticket, a check closed again after a reopen, a menu or settings change and End of Day make them look again.
  • Bumping a ticket: saving a learned prep time saved all the settings and told every screen the settings had changed. Prep times are now saved quietly, at most once a minute.
  • Handheld updates:
    • written to JSON directly instead of through Qt's JSON classes; a new test checks the output against Qt's for every kind of value;
    • tip shares worked out once per round instead of once per screen;
    • the version history built once instead of on every update;
    • a round that took long waits twice as long before the next, so updates never take more than about a third of the store computer's time.

Results

  • Here, at 5× load: worst pause 2,080 ms → 193 ms, none over 250 ms; handhelds' slowest 1 in 20, 363 ms → 98 ms.
  • On the Pi, 13-hour triple-load day: worst pause 4.2 s → 1.7 s; pauses over a second 136 → 31. Every check balanced, and End of Day took 0.3 s.

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

  • Stress test: now realistic. Only the manager works at the store computer; everyone else uses a screen or handheld of their own, over the network.
  • Demo test: the card-name check waits for at least ten card payments. It failed by chance just after midnight UTC, when all of the day's few card payments were keyed in.

Fix

  • Dashboard: the lists (on the clock, best sellers, running low) now scroll inside their cards. On a busy day, names were running off the bottom of the screen.

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

No0ne558 and others added 6 commits October 14, 2026 13:00
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
@No0ne558
No0ne558 merged commit cd48f85 into ViewTouch:main Oct 15, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant