I will add this to my local copy, though I'm not sure how much I'll be
using LyX in the next week or so. We start classes Wednesday.
Another thing I will do is package a version of 2.5.3 with this patch,
and ask Eugene to build a binary for it. Then I can try to get Windows
people to try it.
Riki
On 9/6/26 3:16 PM, Pavel Sanda via lyx-users wrote:
Hi,
I do not experience the lyx-sluggish problem myself so it's difficult test any
proposed solutions.
Tried to push claude to investigate from many angles, but never got something
which would exactly
fit the reports.
I have candidate for a leak when I relax the demand it's 2.5.x only. So it's
present in 2.4 as well,
but perhaps the windows Qt6 transition made it more pronounced?
I am looking for someone who 1) experiences the leak itself and 2) can compile
lyx and test proposed fix(es).
Anyone around?
The patch to test is attached.
Pavel
PS: for @devs this is Claude's theory:
-----------------------
GuiToolbar::update() runs on every keypress and emits updated(), which is connected to
DynamicMenuButton::updateTriggered(). For the "textstyle-apply" and "paste"
buttons, that slot rebuilds the whole dropdown menu each time:
m->clear();
...
Action * act = new Action(func, QIcon(), toqstr(lb), toqstr(s), this);
m->addAction(act);
The actions are parented to this (the button), not to the menu.
QMenu::clear() only deletes actions the menu owns, so these are merely detached
and stay alive as children of the button - for the lifetime of the window.
Every keystroke therefore allocates several new QActions (plus their QStrings)
that are never freed.
Measured on master (Qt5, Linux) with heaptrack, typing into a math-free document, memory still held at exit:
- 100 chars: +0.41 MB, 400 chars: +1.66 MB, 800 chars: +3.32 MB
- i.e. ~4.15 kB per keystroke, perfectly linear and unbounded
Deleting the stale actions before rebuilding drops this from 4.14 to 0.99 kB
per keystroke (~76%).
------
--
lyx-devel mailing list
[email protected]
https://lists.lyx.org/mailman/listinfo/lyx-devel
