Bug 36634 - Formula editor becomes slower and slower
Summary: Formula editor becomes slower and slower
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.0
Keywords: perf
Depends on:
Blocks: Formula-Editor
  Show dependency treegraph
 
Reported: 2011-04-27 06:05 UTC by Alexander Karatarakis
Modified: 2021-11-27 09:37 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Testing formula slowdown (140.68 KB, application/vnd.oasis.opendocument.text)
2013-07-04 23:10 UTC, Alexander Karatarakis
Details
proposed patch (27.68 KB, text/plain)
2016-05-08 20:20 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Karatarakis 2011-04-27 06:05:05 UTC
I extensively used formula editor in writer. If I have just started libreoffice everything is smooth. However, as I open and edit formulas in writer, eventually the process becomes slower and slower. At some point, when double-clicking a formula for editing, the process takes an abnormally long time (~3-4 seconds). Same when exiting the formula after editing.

If I close libreoffice completely (that means close all libreoffice components, like calc/impress, and maybekill relevant processes if necessary) and then fire up writer again, I get smooth speeds again. This is my current workaround, every 20-25 minutes I restart libreoffice completely to return to normal speed.
Comment 1 Björn Michaelsen 2011-12-23 12:08:04 UTC Comment hidden (obsolete)
Comment 2 Alexander Karatarakis 2011-12-25 08:30:06 UTC
Testing with lodev-3.5 beta 2 under Ubuntu 11.10 64-bit: 
the bug is still present and can be reproduced exactly as mentioned on the
first comment.
Slowdown occurs after several formula edits and speed is restored by kill libo and starting it again.
Comment 3 Marcos Souza 2013-05-28 02:11:10 UTC
I can't reproduce this in master 4.1 alpha.

This is still valid?
Comment 4 Alexander Karatarakis 2013-05-28 15:05:09 UTC
Just tested this in Version 4.0.2.2 (Build ID: 400m0(Build:2)) and yes it still occurs. I tested by creating a new file, throwing in like 20 formulas and randomly editing them. At some point there is noticeable slowdown when opening a formula for editing which is "fixed" if I restart LibO. 

If it matters, the formulas include superscripts/subscripts, newlines and symbols +-=()".
Comment 5 Frédéric Wang 2013-06-23 13:23:49 UTC
I was reading the Math parser in order to find how to fix bug 55853 and other MathML export issues. I realized that in various places, String::Copy calls are used (e.g. to test a substring). I'm not really sure about how the String class destructor works, but that could be a potential source of memory leaks. I tried to track them with valgrind but was not able to run soffice within it (or perhaps I didn't wait enough, the libre office dev doc says it is 80 times slower). Anyway, I submitted a patch for review:

https://gerrit.libreoffice.org/#/c/4457/

(note: probably, the code should be migrated to the new string API, but I don't want to do that now)
Comment 6 Commit Notification 2013-06-28 09:58:09 UTC
Frederic Wang committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2ca754cba469533b1ed160b2fadbbe035cf1db34

Remove unused String::Copy in Math (try to fix fdo#36634)



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 7 Frédéric Wang 2013-06-28 10:14:44 UTC
@Alexander Karatarakis: I've pushed a patch that removes suspicious String::Copy but I'm not sure whether or not it fixes memory leaks. I'd appreciate if you could check the daily builds when the patch is integrated and tell if that improves the situation for you. Thanks.
Comment 8 Alexander Karatarakis 2013-06-28 11:10:26 UTC
I will check the bug and report soon.
Comment 9 Alexander Karatarakis 2013-07-04 23:02:09 UTC
Sorry, for the delay. I was not able to install the daily build in my main machine (Ubuntu) but managed to obtain one with windows to test there. 

The bug still occurs. I tried a daily build of 04-July-2013 which I assume contains the patch. If it helps, I can test the stable release vs the daily one in the same machine (the windows one) to try to get an idea of whether the bug is better with or without the patch. (I don't have an accurate view now because previous tests where on my main machine - different hardware, different OS).
Comment 10 Alexander Karatarakis 2013-07-04 23:10:28 UTC
Created attachment 82055 [details]
Testing formula slowdown

I attach a sample file I use for my tests in case someone wants to test. It just has a bunch of formulas. For the tests I repeatedly open random formulas for editing, maybe make edits and then close them again, make random copies of existing formulas and open/close them too and so forth. Eventually I get the slowdown.
Comment 11 Marcos Souza 2013-09-02 16:29:38 UTC
Hi Alexander Karatarakis,

I could not reproduce this with LibreOffice 4.0.2.2

This issue still exists in your machine?
Comment 12 Alexander Karatarakis 2013-09-03 10:22:12 UTC
Yes, it still occurs in 4.0.2.2 (which is the default version on Ubuntu 13.04 and the one I use daily).
Comment 13 QA Administrators 2015-04-01 14:43:02 UTC Comment hidden (obsolete)
Comment 14 Alexander Karatarakis 2015-05-03 12:43:25 UTC
Still an issue Version: 4.4.2.2 (under Ubuntu 14.04 64-bit)
Comment 15 Julien Nabet 2016-05-08 20:20:40 UTC
Created attachment 124916 [details]
proposed patch

A conflict must be resolved with it.
Comment 16 Julien Nabet 2016-05-08 21:08:15 UTC
Comment on attachment 124916 [details]
proposed patch

I submitted for review the modified patch here https://gerrit.libreoffice.org/#/c/24775/
Comment 17 Markus Mohrhard 2016-05-09 13:48:21 UTC
Did anyone here actually profile the bug and check what is slowing down? Trying to fix performance problems without profiling is nearly always a lost cause.
Comment 18 Julien Nabet 2016-05-09 14:14:08 UTC
(In reply to Markus Mohrhard from comment #17)
> Did anyone here actually profile the bug and check what is slowing down?
> Trying to fix performance problems without profiling is nearly always a lost
> cause.

I must recognize, I didn't :-(
I just noticed this token array and this loop ; I should have put RELATED in the patch since I'm not sure it'll be ok with this.
Meanwhile, I must fix the new conflict + Linux CI failing.
Comment 19 Julien Nabet 2016-05-10 07:37:34 UTC
Following https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_callgrind_trace, I'm rebuilding LO 
sources since I had to remove enable-dbgutil and add enable-symbols.

Meanwhile, I fixed the conflict but still have a failing Linux Jenkins build (that I don't reproduce in local). I'll try to add "OUString" before each string in the map (as Markus had advised on IRC).
Comment 20 Aron Budea 2016-05-10 08:36:08 UTC
Julien, can you try changing this:
std::unordered_map< const OUString, SmTokenEntry, OUStringHash>

to this: std::unordered_map< OUString, SmTokenEntry, OUStringHash >
Comment 21 Julien Nabet 2016-05-11 19:20:57 UTC
I don't know if I did well with Cachegrind but indeed, I see nothing about starmath part.
Impossible to upload the file which is >10MB here https://wiki.documentfoundation.org/QA/Bugzilla/Attachments/Temporary_Storage_for_Big_Files

So it seems I built LO from scratch without enable-dbgutil for nothing :-(

Anyway, I still think replacing this array by an unordered_map could be a good thing, let's wait for the review. If I'm wrong, I'll just abandon it.
Comment 22 Julien Nabet 2016-05-14 10:51:28 UTC
(In reply to Aron Budea from comment #20)
> Julien, can you try changing this:
> std::unordered_map< const OUString, SmTokenEntry, OUStringHash>
> 
> to this: std::unordered_map< OUString, SmTokenEntry, OUStringHash >

Sorry I forgot to thank you for this tip, so thank you! :)
I wouldn't have guessed by myself when looking at the build errors.
Comment 23 Julien Nabet 2016-05-16 07:48:42 UTC
The patch to review was wrong, I've got no idea how to help here, so uncc myself.
Comment 24 Roman Kuznetsov 2018-07-13 19:22:37 UTC
there is a delay when I open/close Formula editor, but only 1-2 sec after 1 hour work with file from attach.

But today 2018 year and my hardware is Intel Core i5 with 6Gb of memory

My opinion -> WFM

People, are there any opinion?
Comment 25 Buovjaga 2018-07-14 15:25:11 UTC
(In reply to kompilainenn from comment #24)
> there is a delay when I open/close Formula editor, but only 1-2 sec after 1
> hour work with file from attach.
> 
> But today 2018 year and my hardware is Intel Core i5 with 6Gb of memory
> 
> My opinion -> WFM
> 
> People, are there any opinion?

I did not spend 1 hour, only edited all the formulas on the first page. No increasing of time observed.

The long formulas on the second page cause a lot of slowness even straight after opening the file. This only happens on Windows and is a regression. I will bibisect it and open a new report.

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 1a8435a23e84f3ceeee580eb9d4404a738d98888
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-07-12_22:57:12
Locale: fi-FI (fi_FI); Calc: group threaded
Comment 26 QA Administrators 2019-11-25 03:31:07 UTC Comment hidden (obsolete)
Comment 27 QA Administrators 2021-11-25 05:22:15 UTC Comment hidden (obsolete)
Comment 28 Alexander Karatarakis 2021-11-27 09:37:27 UTC
Version: 7.2.3.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.2.3~rc2-0ubuntu0.20.04.1~lo1
Calc: threaded

Works for me with the above version! Even after opening/closing formulas (including the big ones) for a while, the time seems to remain constant and not become progressively worse.