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.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
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
Slowdown occurs after several formula edits and speed is restored by kill libo and starting it again.
I can't reproduce this in master 4.1 alpha.
This is still valid?
Just tested this in Version 184.108.40.206 (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 +-=()".
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:
(note: probably, the code should be migrated to the new string API, but I don't want to do that now)
Frederic Wang committed a patch related to this issue.
It has been pushed to "master":
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:
Affected users are encouraged to test the fix and report feedback.
@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.
I will check the bug and report soon.
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).
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.
Hi Alexander Karatarakis,
I could not reproduce this with LibreOffice 220.127.116.11
This issue still exists in your machine?
Yes, it still occurs in 18.104.22.168 (which is the default version on Ubuntu 13.04 and the one I use daily).
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
*Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later)
*If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
*If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
*Update the version field
*Reply via email (please reply directly on the bug tracker)
*Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Still an issue Version: 22.214.171.124 (under Ubuntu 14.04 64-bit)
Created attachment 124916 [details]
A conflict must be resolved with it.
Comment on attachment 124916 [details]
I submitted for review the modified patch here https://gerrit.libreoffice.org/#/c/24775/
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.
(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
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.
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).
Julien, can you try changing this:
std::unordered_map< const OUString, SmTokenEntry, OUStringHash>
to this: std::unordered_map< OUString, SmTokenEntry, OUStringHash >
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.
(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.
The patch to review was wrong, I've got no idea how to help here, so uncc myself.
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?
(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: 126.96.36.199.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