Performance degradation with Qt6

[PierreRaybaut]

While the whole stack (PythonQwt, guidata and PlotPy) is compatible with PyQt5, PyQt6 and PySide6, there are some differences in terms of performance between Qt5 and Qt6.

For example, the following benchmark has been done on Windows 10 with Python 3.10 (on a quite limited VM):

In other words, results are +50% slower with PyQt6 (and almost +100% slower with PySide6) than with PyQt5.

We need to investigate this and to come with an action plan before Qt5 end-of-life, that is May 25th 2025.

[PierreRaybaut]

Here are the profiling stats:

We can see that some intermediate level methods (in PythonQwt) are called ~2x more when using Qt6. When tracking back the call stack, it seems that this is due to an internal change in Qt which has the effect of calling internal methods related to widget resizing and drawing twice more than before. In other words, there is not much we can do in PlotPyStack (in PythonQwt, to be precise) apart from avoiding unnecessary widget refresh calls, but this kind of optimization has already been done in PythonQwt.
profiling_stats-PyQt5.txt
profiling_stats-PyQt6.txt
profiling_stats-PySide6.txt

[PierreRaybaut]

PythonQwt #93 fix — impact on this PlotPy issue

The Qt6 performance gap reported here was traced to PythonQwt internals (per-call Python overhead amplified by the heavier PyQt6 / PySide6 binding cost). It has been investigated and fixed on the PythonQwt side: see PlotPyStack/PythonQwt#93 for the full optimization log (5 phases: cProfile-driven, line-profiler-driven, screenshot regression analysis, a Qt5 compatibility gate, and a final pass targeting the residual Qt5↔Qt6 gap caused by PyQt6's enum.Flag arithmetic and sip per-call dispatch cost).

Measured impact on this exact PlotPy load test

plotpy/tests/benchmarks/test_loadtest.py was re-run on the same Windows 11 / Python 3.11.9 machine, with 60 plot widgets and 5 runs per cell, against three commits of PythonQwt: master (1ab70cd), the end of phase 4 (ad24e61), and the end of phase 5 (ecee0f4). All numbers are the mean of 5 runs in milliseconds.

Binding	PythonQwt master	fix/93 (phase 4)	fix/93 (phase 5)	Speedup vs master
PyQt5	27 217 ms	17 768 ms	18 157 ms	×1.50
PyQt6	44 181 ms	22 271 ms	21 498 ms	×2.05
PySide6	95 789 ms	28 495 ms	25 211 ms	×3.80

Cross-binding gap

Comparison	master	fix (phase 4)	fix (phase 5)
PyQt6 vs PyQt5	+62 % slower	+25 % slower	+18 % slower
PySide6 vs PyQt5	+252 % slower	+60 % slower	+39 % slower

The original symptom — "results are +50 % slower with PyQt6 (and almost +100 % slower with PySide6) than with PyQt5" — is largely resolved. With the phase-5 fix the load test is roughly twice as fast on PyQt6 and almost four times as fast on PySide6 in absolute terms, and the relative penalty for moving from PyQt5 to PyQt6 / PySide6 drops from +62 % / +252 % to +18 % / +39 %.

PySide6 is the binding that benefits most from the fix in both absolute (×3.8) and relative terms (the cross-binding gap collapses by an order of magnitude). This is consistent with the diagnostic finding: PySide6 has the heaviest per-call binding cost of the three, so any per-call overhead removed in PythonQwt translates directly into proportional savings.

Phase 5 — further closing of the residual Qt6 gap

A second diagnostic pass on the post-phase-4 tip identified that the remaining +20 % PyQt6 overhead on the PythonQwt micro load test was concentrated in three Qt6-specific costs:

1. Python enum.Flag arithmetic — PyQt6 wraps Qt enums as enum.Flag instances, so every flags & Qt.SomeFlag test goes through Python's enum.__and__ (~6 µs each) instead of a native int bitwise op (~50 ns on PyQt5). The single worst offender was QwtPainterCommand doing twelve successive flag tests per painter command.
2. QFont.key() is ~3× slower per call on PyQt6 (sip dispatch cost for cheap getters: 3.3 µs on PyQt5 vs 9.3 µs on PyQt6).
3. PyQt6 returns fresh Python wrappers around the same QFont between calls, so the previous id(font)-keyed cache missed ~92 % of the time and fell through to (2).

The phase-5 changes (in qwt/painter_command.py, qwt/graphic.py, qwt/text.py) cache the relevant QPaintEngine.DirtyXxx and Qt.AlignXxx flags as plain ints once at module import time and bitwise-test against them, and replace the font.key()-based cache with a tuple-key cache that never calls font.key(). The Qt5-specific gate added in phase 4 was removed (no longer needed since the issue it worked around can no longer arise).

Impact on the PythonQwt micro load test (10 runs each, median ms):

Config	PyQt5	PyQt6	PyQt6 / PyQt5
master (no optimisations)	798	1 000	+25 %
fix/93 end of phase 4	511	611	+20 %
fix/93 + phase 5	539	590	+9 %

PyQt5 is essentially unchanged by phase 5 (the int-flag constants are no-ops there). PyQt6 dropped another ~20 ms median; the PyQt6↔PyQt5 ratio more than halved (from +20 % to +9 %). The remaining +9 % is the structural sip-dispatch cost on cheap Qt getters that is not removable from PythonQwt — only mitigated by calling Qt fewer times per render, which phases 1–5 already pursue aggressively.

On the PlotPy load test (table at the top), phase 5 brings a small additional improvement on PyQt6 (−3 %) and a more visible one on PySide6 (−12 %), confirming the same trend at full-application scale.

Visual regression status

A full screenshot sweep over the 22 PythonQwt visual tests on the three bindings shows zero new visual regressions introduced by the fix — output is byte-identical to master on every reproducible test, on every binding. The full PythonQwt test suite (26 passed / 1 skipped on each binding) continues to pass after phase 5. Details and per-test matrix in the PythonQwt issue.

[PierreRaybaut]

This is fixed by PythonQwt Issue #93

Before closing this issue...

No PlotPy code change is needed. Once a PythonQwt release including the fix is published, simply bump the PythonQwt minimum version pin in PlotPy's requirements to pick up the speedup automatically.