LyX2 slow with complex documents?

[John McCabe-Dansted]

Is it more convenient if I include the patch that caused the
regression in my email, if it is small, as below?

It seems that this code should only be called if the math inset has
actually been modified, but that it is being called constantly, even
on cursor movement outside the math inset.

------------------------------------------------------------------------
r30497 | forenr | 2009-07-12 18:52:28 +0800 (Sun, 12 Jul 2009) | 2 lines

Fix bug #6063: Keylogger lyx::lyxbreaker: Crash in Math.

Index: src/frontends/qt4/GuiCompleter.cpp
===================================================================
--- src/frontends/qt4/GuiCompleter.cpp (revision 30496)
+++ src/frontends/qt4/GuiCompleter.cpp (revision 30497)
@@ -313,6 +313,11 @@
if (!inlineVisible() && possibleInlineState && start
&& cur.inset().automaticInlineCompletion())
inline_timer_.start(int(lyxrc.completion_inline_delay * 1000));
+ else {
+ // no inline completion, hence a metrics update is needed
+ if (!(cur.disp_.update() & Update::Force))
+ cur.updateFlags(cur.disp_.update() | Update::SinglePar);
+ }

// update prefix if any completion is possible
bool modelActive = modelActive_ && model()->rowCount() > 0;

[John McCabe-Dansted]

 1) Open a complex lyx file with many math insets, macros etc. (e.g.
http://www.csse.uwa.edu.au/~john/drafts/Thesis_Background.lyx, or just
create a new document and fill the screen with "$x$ x", where $x$
represents math-mode x)
 2) Hold down X (or any other normal key) for a few seconds.
 3) Note that LyX cannot keep up with typematic rate, so X's will
continue to appear a couple of seconds after release key.

This appears to be a regression in r30497 by forenr.

I append the the output of the benchmark to the end of my email. This
creates a huge paragraph with many in-text math insets, then moves the
cursor 1000 times within normal text by simulating the left and right
arrows. It shows at 30496 this takes 8 seconds of CPU time (about 8ms
per move). From 30497 on it takes about 160 seconds of CPU time, an
increase of 20x!

With --enable-build-type=rel there is still a significant difference
(from 1.8sec to 5.8sec of CPU time). This is only a 3x slowdown but it
is enough to make LyX feel sluggish, and even become unusable if we
fill the screen in in-text math insets (Core2Duo with 1080p monitor)

Can we reimplement r30497 in a more efficient way?

--

20010 35.58user 0.21system 3:33.53elapsed 16%CPU
25000 6.54user 0.17system 3:08.83elapsed 3%CPU
26000 57.61user 0.08system 1:03.22elapsed 91%CPU
27418 5.51user 0.18system 3:08.96elapsed 3%CPU
29473 8.23user 0.17system 3:11.29elapsed 4%CPU
29479 8.43user 0.30system 3:10.73elapsed 4%CPU
29731 5.92user 0.28system 3:11.95elapsed 3%CPU
29990 8.17user 0.27system 3:13.94elapsed 4%CPU
30496 8.44user 0.25system 3:04.55elapsed 4%CPU
30497 157.57user 0.30system 4:34.15elapsed 57%CPU
30507 165.95user 0.48system 3:11.78elapsed 86%CPU
30612 173.50user 0.49system 4:58.76elapsed 58%CPU
31024 186.28user 0.49system 5:16.40elapsed 59%CPU
31125 189.29user 0.48system 5:18.19elapsed 59%CPU
...
39243 176.04user 0.47system 5:13.77elapsed 56%CPU

[Jean-Marc Lasgouttes]

Post by John McCabe-Dansted
It shows at 30496 this takes 8 seconds of CPU time (about 8ms
per move). From 30497 on it takes about 160 seconds of CPU time, an
increase of 20x!
With --enable-build-type=rel there is still a significant difference
(from 1.8sec to 5.8sec of CPU time). This is only a 3x slowdown but it
is enough to make LyX feel sluggish, and even become unusable if we
fill the screen in in-text math insets (Core2Duo with 1080p monitor)

Please never do profiling with stdlib-debug on, as it is really
meaningless. The only case where this may matter is when developers'
work is hampered by LyX slowness.

JMarc

[Enrico Forestieri]

Post by John McCabe-Dansted
It seems that this code should only be called if the math inset has
actually been modified, but that it is being called constantly, even
on cursor movement outside the math inset.

Does the attached patch help? However, I don't see any difference even
reverting r30497.

[John McCabe-Dansted]

Post by Enrico Forestieri

Post by John McCabe-Dansted
It seems that this code should only be called if the math inset has
actually been modified, but that it is being called constantly, even
on cursor movement outside the math inset.

Does the attached patch help? However, I don't see any difference even
reverting r30497.

It certainly helps with the benchmark, which is run off my desktop.

However, it doesn't make any noticeable difference on my Laptop.
Perhaps it depends on what X-server is being run, and what
acceleration options are active.

[Enrico Forestieri]

Post by John McCabe-Dansted

Post by Enrico Forestieri

Post by John McCabe-Dansted
It seems that this code should only be called if the math inset has
actually been modified, but that it is being called constantly, even
on cursor movement outside the math inset.

Does the attached patch help? However, I don't see any difference even
reverting r30497.

It certainly helps with the benchmark, which is run off my desktop.

I'll commit it, then.

Post by John McCabe-Dansted
However, it doesn't make any noticeable difference on my Laptop.

This is also what I find, even reverting r30497, as said.

Post by John McCabe-Dansted
Perhaps it depends on what X-server is being run, and what
acceleration options are active.

It is certainly a X-server thingie, as I don't see the problem on Windows.
After releasing a key being held pressed for a few seconds, characters
stop appearing on screen immediately.