Aglet

How to verify large-list performance as row counts grow

Verification for a large list must cover the growth boundary and the work people do after the first rows appear. Use matched fixtures at representative sizes, compare server and interaction timing, and check row completeness, ordering, focus, selection, and pagination for every tested case.

Check whether the outcome improved

  1. Run matched size comparisons

    Use small, representative, and near-boundary row counts with identical fields, filters, sort, viewport, and account assumptions. Record first visible rows, full completion, request count, response bytes, and interaction response. Keep fixture generation deterministic so a faster run is comparable.

  2. Exercise the expensive list actions

    Sort, filter, select, expand, paginate, and navigate away using the same sequence that exposed the issue. Confirm row identifiers, counts, ordering, focus, keyboard movement, and loading recovery. Watch for cost shifted from initial render into each action or into cleanup when leaving the route.

  3. Probe data completeness and failure paths

    Check empty, partial, error, and next-page states at each size. Confirm that no records disappear, repeat, or silently change fields when the list is split or narrowed. Record whether a failed page leaves a recoverable control and whether prior rows remain understandable.

What to carry forward

Report improved, regressed, unchanged, or inconclusive with size-specific timing and correctness evidence. A change passes only when the targeted list operation remains usable near its intended boundary, records and navigation stay correct, and any untested larger scale is clearly identified.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow