[Perf] Profile grid-related slowness and decide between optimisation, PyO3, or rewrite

[michaelbeijer]

Background

Working in the grid in Supervertaler Workbench feels sluggish in several places — slow cold start, lag while scrolling/typing in large projects, latency on segment-to-segment navigation, and noticeable wait on batch operations. The instinct has been to blame Python and consider a rewrite (an earlier Tauri/Rust prototype lives in D:\Dev\Sv\Supervertaler2).

Before committing to a multi-month rewrite, the goal of this issue is to measure where the time actually goes and decide between three very different fix paths:

1. Targeted PyQt6 / architecture tuning (cheapest, days of work)
2. A small Rust extension via PyO3 for genuine inner-loop hot paths (weeks of work, keeps the rest of the codebase intact)
3. Full rewrite in Tauri/Rust or native Rust GUI (months of work, last resort)

The hypothesis going in: most perceived slowness is architectural (Qt model layer over-calling, synchronous TM/term lookups on focus change, no virtualization, etc.) rather than Python-the-language. A profiling pass will tell us whether that's right.

---

One-time setup

cd D:\Dev\Sv\Supervertaler
.\.venv\Scripts\Activate.ps1
pip install py-spy snakeviz

• py-spy — samples a running process, no code changes needed. Best for "the app is sluggish right now, what's it doing?"
• snakeviz — flame-graph viewer for cProfile output. Best for analysing a specific operation after the fact.
• cProfile — ships with Python, no install needed.

---

Test corpus

Need one realistic large project to profile against:

• An SDLXLIFF or DOCX-derived project with 2,000–10,000 segments
• A TM attached with at least 50k–500k TUs so lookups exercise the index
• Optional: a MultiTerm .sdltb attached

If no real project is to hand, generate a synthetic one.

---

Scenarios to profile

Five scenarios, ordered from "almost certainly slow" to "probably fine but let's confirm":

1. Cold open of a large project

Most likely Python-startup + XML parsing dominated.

python -X importtime Supervertaler.py 2> import-time.log
# open the test project, close as soon as it's fully loaded

Also capture wall-clock: stopwatch from double-click to fully-loaded grid.

2. Scrolling through the grid

Most likely architectural (model overuse, no virtualization).

py-spy record -o scroll.svg --pid <workbench-pid> --duration 15
# scroll vigorously through the grid for ~15 seconds

3. Typing in a segment

Most likely signal-storm / re-render on every keystroke.

py-spy record -o typing.svg --pid <workbench-pid> --duration 10
# type a 100-char target translation at normal speed

4. Segment-to-segment navigation

Likely culprit: TM lookups, term highlighting, match panel updates firing synchronously on focus change.

py-spy record -o navigate.svg --pid <workbench-pid> --duration 15
# Down-arrow through 50 segments at normal review pace

5. Batch op (e.g. find/replace across all segments)

Most likely an inner-loop candidate for a Rust extension.

py-spy record -o batch.svg --pid <workbench-pid> --duration 30
# trigger the batch op

---

Output collection

Drop everything in D:\Dev\Sv\Supervertaler\.dev\profiling-<date>\:

• import-time.log
• scroll.svg, typing.svg, navigate.svg, batch.svg
• Wall-clock numbers (plain text: "cold open: 8.2s", "type 100 chars: noticeable lag at ~30 chars in")
• Short note on what felt slow during each scenario

Flame-graph SVGs are the gold here — they show exactly which functions ate the time.

---

Diagnosis matrix

For each flame graph, the fix shape follows directly from the pattern:

Pattern in the flame graph	Diagnosis	Fix
Most time in QAbstractTableModel.data() or paintEvent	Grid architecture — over-calling the model	PyQt6 tuning: cache, batch, virtualisation audit
Most time in Python for loops over segments	Inner-loop hot path	Small PyO3 Rust extension
Most time in requests / httpx / urllib / sqlite3	I/O or network bound	Background thread, debounce, cache
Most time in xml / lxml / etree parsing	File-parse cost	lxml tuning, lazy loading, or Rust XML parser via PyO3
Time spread thinly across many functions, none dominant	Genuinely systemic	The rewrite case starts to firm up

---

Predicted outcome

Most likely: scenarios 1 and 5 will reveal Python/parsing bottlenecks fixable by a PyO3 extension in days, and scenarios 2–4 will reveal architectural issues in the Qt model layer that have nothing to do with Python being slow.

If that's wrong and everything is uniformly slow with no clear hot spots, that's when Tauri/Rust gets seriously reconsidered.

---

Time budget

• Setup + test project: 30 min
• Five profiling runs: 45 min
• Analysis + first round of fixes: 1–2 hours
• Decision: same day

Total: roughly a half-day. Cheap relative to a multi-month rewrite.

---

Definition of done

• All five flame graphs captured and saved to the repo (or a gist).
• A summary comment on this issue identifying the dominant bottleneck per scenario.
• A decision recorded here: PyQt6 tuning / PyO3 extension / rewrite, with concrete next steps for whichever path is chosen.

[michaelbeijer]

Profiling results — 2026-05-16

Half-day profiling pass done against the BRANTS project (NL→EN, 289 segments, single TM, single termbase). Test corpus is smaller than the issue's 2k–10k target — scenarios 2 (scroll) and 5 (batch) are accordingly undersampled — but the dominant patterns are unambiguous. Cold-open (scenario 1) deferred to a separate session.

Flame graphs and raw output in .dev/profiling-2026-05-16/.

TL;DR

Python is not the bottleneck. Architecture is. No PyO3 needed for any scenario in this trace. No rewrite case.

Per-scenario results

Scenario	Samples	Dominant pattern	Diagnosis
2 Scroll (15 s)	7,495	No Python frames visible on grid paint path	Qt handles scroll in C++. Virtualisation working. Not a problem.
3 Typing (10 s)	4,995	~1% of MainThread on keyPressEvent + debouncer + highlighter	Debouncer working as designed. Not a problem.
4 Navigation (15 s)	8,602	TM lookups (search_fuzzy_matches, _search_single_tm_fuzzy, get_exact_match) running on background QThreads, ~18% of all samples	Architecturally sound. ~15 ms/segment in background. Not a problem for interactive nav.
5 Batch (30 s)	15,603	load_segments_to_grid + per-cell _rebuild_grid_stylesheet + _apply_row_color re-firing during find/replace	PyQt6 tuning case.
—	—	_poll_trados_bridge consumed ~35% of MainThread in every scenario	Independent bug. Biggest single win.

Top finding: _poll_trados_bridge (the elephant)

Visible in scroll, typing, navigation, and batch flame graphs as ~35% of MainThread CPU. Confirmed by code reading:

• ChatViewWidget.__init__ (modules/chat_view_widget.py L333–336) starts a 3 s QTimer per widget.
• UnifiedPromptManager instantiates at least two ChatViewWidgets (modules/unified_prompt_manager_qt.py L944 + L1161) — AI tab + grid — and an on-demand third from _open_chat_window.
• is_available() (modules/trados_bridge_client.py L175) calls requests.get(url, timeout=0.5) with no shared Session — fresh TCP socket every call (visible as _new_conn → create_connection → connect → _send_output chain in every flame graph).
• When the Trados bridge isn't responding, the 500 ms timeout × 2 widgets per 3 s ≈ 33% of MainThread, matching the observed 35%.

Today's session had two Workbench-side fingerprints of this in the wild: noticeably less snappy than expected during typing, and the earlier shutdown crash in sip.cp312-win_amd64.pyd came right after a poll cycle.

Fix shape (cheap, hours not days):

1. Shared requests.Session() on TradosBridgeClient for connection pooling.
2. Run is_available() off the main thread — either QNetworkAccessManager (Qt-native, async) or a QThreadPool worker with QMetaObject.invokeMethod to marshal the result back. The timer stays on the main thread; the HTTP call doesn't.
3. Exponential backoff when unreachable: 3 s → 10 s → 30 s, reset on success.
4. Single shared poll across all ChatViewWidget instances (singleton timer, broadcast result via signal) — there's no reason 3 widgets all probe the same endpoint independently.

Any one of these alone would help; (2) is the one that meaningfully unsticks the main thread.

Second finding: find/replace re-renders the entire grid per call

Per Supervertaler.py L42542–L42548, find_next_match calls self.load_segments_to_grid() on first invocation just to toggle row visibility. load_segments_to_grid re-creates editor widgets, which each call _rebuild_grid_stylesheet per cell (Supervertaler.py L4963). For a 289-row project, the batch trace shows load_segments_to_grid line-frames summing to ~64% of MainThread for the duration; with 5k+ segments this gets worse super-linearly.

Fix shape:

1. Drop the load_segments_to_grid() call in find_next_match / find_all_matches. The grid is already loaded; only setRowHidden() is needed.
2. Wrap the visibility loop in self.table.setUpdatesEnabled(False) / …(True).
3. If _rebuild_grid_stylesheet must fire for highlighted rows, debounce to one rebuild per batch via QTimer.singleShot(0, …).

What this means for the three-path decision

Path	Verdict
1. PyQt6 / architecture tuning	Yes. This is where the wins are. ~1 day of work covers both the bridge-poll fix and the find/replace fix. Expected impact: typing/navigation feel ~30% snappier, batch ops complete dramatically faster on larger projects.
2. Small PyO3 Rust extension	Not needed yet. No Python inner loop dominated any trace. The difflib.SequenceMatcher use in _search_single_tm_fuzzy is the only realistic future candidate, but only matters for huge TM batches (50k+ TUs), not for interactive work. Park as a future option contingent on profiling against a 10k-segment + 500k-TU corpus.
3. Full rewrite in Tauri/Rust	No case for it from this data. No uniform slowness, no Python-language ceiling — discrete fixable bottlenecks. The Supervertaler2 prototype stays parked.

Caveats

• 289 segments is small. The architectural patterns surface here, but scrolling and batch op should be re-profiled against a 5k–10k-segment project before declaring scenario 2 fully clean — Qt virtualization can hide problems at small N. Adding to backlog as a follow-up.
• Cold open (scenario 1) not measured. Suspect Python import time dominates; needs python -X importtime on next cold start.
• One side observation: Supervertaler.py is 59,670 lines in a single file. Not a perf issue, but it's the kind of size where simple refactors get expensive. Worth flagging separately.

[michaelbeijer]

Side note: what scenario 5 actually recorded

Worth flagging — during the session that produced these traces, I told Michael I'd run "find & replace across all segments". Looking at the flame graph after the fact, no replace path ever fired:

• _fr_find_next / find_next_match — 1,961 samples
• _fr_replace_all / replace_all_matches — 0 samples
• replace_current_match — 0 samples
• setPlainText / record_undo_state / any re.sub in the replace path — 0 samples

So the click landed on Find next, not Replace all. The two buttons sit adjacent in the same horizontal row at Supervertaler.py:42229–42251 (Find next | Find all | Replace this | Replace all | Highlight all | Clear highlights). Easy to mis-click — and the user-perceived outcome ("nothing was replaced") is the only signal that anything went wrong, since "Find next" succeeds silently.

This doesn't change any of the perf findings above — the architectural cost of find_next_match (full load_segments_to_grid to toggle row visibility) stands regardless. But it's a separate small UX win worth noting:

1. Visually group the buttons: [Find next | Find all | Highlight all] then a separator then [Replace this | Replace all], ideally with a different background colour on the destructive ones.
2. Neither the find nor the replace input has a returnPressed binding in the F&R dialog (verified by grep against Supervertaler.py) — there's no keyboard shortcut for replace at all. Wiring Enter in replace field → _fr_replace_all with a confirmation prompt would help.

Filing as a comment here rather than a new issue since it surfaced from the same profiling session.

[michaelbeijer]

Fixes landed in v1.10.42 — before/after profiling

All five flame graphs re-captured against the same project (BRANTS, 289 segments) after the fixes from v1.10.42. All v1.10.42 traces in .dev/profiling-2026-05-16/*-v1.10.42.svg.

Bridge poll fix — verified clean

Idle baseline (10 s, no UI input): every Python frame in the trace is in an idle-wait syscall. Zero _poll_trados_bridge, zero is_available, zero requests/urllib/http.client. MainThread is 100% in the Qt event-loop idle wait. The new TradosBridgePoller's 60 s backoff means a Trados-less idle window genuinely costs nothing.

Active session evidence the poll is alive and behaving: the 30 s batch trace caught the poll firing mid-window — 18 samples in probe_blocking, 18 in _load_handshake, 19 in _ProbeRunnable.run — every single one on the QThreadPool worker, zero on MainThread. Exactly the design intent.

Per-scenario before/after (MainThread samples)

Scenario	Frame	v1.10.41	v1.10.42	Δ
Idle	_poll_trados_bridge	n/a (~35% MainThread routinely)	0	gone
Scroll (15 s)	_poll_trados_bridge	520 (~35% MainThread)	0	gone
Scroll	paint / drawPrimitive / eventFilter	crowded out	now visible (~85 total)	real scroll work surfaces
Typing (10 s)	_poll_trados_bridge	391 (~39% MainThread)	0	gone
Typing	Total typing-related Python work	~50 (~5% MainThread)	6 (~0.6%)	~8× less
Navigation (15 s)	_poll_trados_bridge	520 (~35% MainThread)	0	gone
Navigation	MainThread total	1,499 (17.4%)	1,498 (14.3%)	~3 percentage points back
Batch (30 s)	load_segments_to_grid	~1,925 samples (huge)	0	gone
Batch	_rebuild_grid_stylesheet	~818 (~27% MainThread)	0	gone
Batch	_apply_row_color / set_background_color / apply_grid_font_size	~889 combined	trivial	gone
Batch	_poll_trados_bridge on MainThread	344 (~11% MainThread)	0	gone (moved to worker)
Batch	_fr_replace_all + replace_all_matches	0 (never invoked due to mis-click)	883 (~29% MainThread)	Replace All actually works + button is amber + Enter key wired

What this means

• Fix 1 (bridge poll) — definitively done. Zero MainThread cost in any scenario; HTTP probe lives on QThreadPool with 3 s → 60 s exponential backoff; one shared requests.Session across all call sites; pref toggles propagate via pref_changed signal so chip state stays in sync across chat views without polling.
• Fix 2 (find/replace grid reload) — definitively done. All four touch points (find_next_match, find_all_matches, highlight_all_matches, clear_search_highlights) no longer call load_segments_to_grid(). Replace All cost dropped to just the actual replace work (~29% MainThread for the heaviest operation in any of these traces), which is what you'd expect.
• Fix 3 (mis-click affordance) — verified via Replace All actually firing this run. The amber Replace cluster + vertical separator made the right button obvious; the returnPressed binding on the Replace field also works.

What's still on the table

Nothing urgent. The future-PyO3 candidate (difflib.ratio / get_matching_blocks inside _search_single_tm_fuzzy) still shows ~100–200 samples in the navigation trace but it's on background QThreads and only matters for huge TMs. Park.

Cold open (scenario 1) still deferred. Suggest capturing it on the next cold start before committing to or against any further work on Workbench perf.

Closing notes

Half-day investment from raw profiling to landed fixes to verified regression-free improvement. No PyO3 written. No rewrite. PyQt6/architecture tuning was the right call.