Bug Hunting Session
Bug 101213 - Various performance regressions (rendering and recalcing)
Summary: Various performance regressions (rendering and recalcing)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.1.5.2 release
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.3.0 target:5.2.1 target:5.1.6
Keywords: perf, regression
: 101414 101680 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-07-30 00:12 UTC by marty8
Modified: 2016-09-01 11:38 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Performance issue log (792.11 KB, text/plain)
2016-08-04 16:52 UTC, Victor Campillo
Details
Test File Contain Pivots , References, Formulas etc. (2.49 MB, application/vnd.oasis.opendocument.spreadsheet)
2016-08-19 13:38 UTC, pharmankur
Details
CPU Use while opening Performance_test.ods (110.73 KB, image/png)
2016-08-19 13:42 UTC, pharmankur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description marty8 2016-07-30 00:12:48 UTC
I just upgraded to 5.1.5.2 using Linux MInt 17.3 Rosa.
This is the first upgrade that is much slower (In all respects)than previous versions. Screen rendering is slow as well as recalculating the spreadsheet's downloaded and inputted data.
I'm a very big fan of LibreOffice and hope this problem can be corrected. It has never happened before.
Thank you in advance.
Comment 1 m.a.riosv 2016-07-30 10:55:46 UTC
Please try resetting the user profile, sometimes solves strange issues.
https://wiki.documentfoundation.org/UserProfile
Usually it's enough renaming/deleting the file "user/registrymodifications.xcu",  it affects all the options in Menu/Tools/Options, and the files "user/basic/dialog.xlc" and "scrip.xlc" are overwritten, additionally custom colors in "user/config/standard.soc" are lost.
Comment 2 Jamieson C 2016-07-31 18:19:50 UTC
I am also experiencing this issue after updating via Ubuntu 12.04 LTS with the LibreOffice PPA (http://ppa.launchpad.net/libreoffice/ppa/ubuntu) added to software sources.

From the LibreOffice help window:

Version: 5.1.5.2
Build ID: 1:5.1.5~rc2-0ubuntu1~trusty1
CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group

The following Calc actions are very slow (1-2 seconds per action) after the update.

* Switching between workbook tabs
* Inserting rows
* Fill Down using Ctrl+D
* Scrolling up and down using the PgUp and PgDn keys

(The above list is just those actions I've been performing, and may not be all-inclusive.)

Delay sometimes seems to be related to sheet size (but largest sheet only has 1600 rows) or possibly formula complexity (some sheets have dozens of SUMIFS or SUMPRODUCT calculations).

Removing my profile ~/.config/libreoffice/4/user and creating a fresh profile did not have any effect.
Comment 3 marty8 2016-07-31 21:45:24 UTC
(In reply to m.a.riosv from comment #1)
> Please try resetting the user profile, sometimes solves strange issues.
> https://wiki.documentfoundation.org/UserProfile
> Usually it's enough renaming/deleting the file
> "user/registrymodifications.xcu",  it affects all the options in
> Menu/Tools/Options, and the files "user/basic/dialog.xlc" and "scrip.xlc"
> are overwritten, additionally custom colors in "user/config/standard.soc"
> are lost.

I have done everything in your e-mail, but nothing has changed. It still does most everything very slowly. Is there a way for me to return to the previous excellent version?
Comment 4 m.a.riosv 2016-07-31 21:55:37 UTC
Please test if disabling OpenGL in Menu/Tools/Options/LibreOffice/View - Use OpenGL for all rendering and restart, has some effect.

If it doesn't work, to return the previous version, uninstall the actual and install the previous, you can find all LibreOffice versions for all systems in:
https://downloadarchive.documentfoundation.org/libreoffice/old/?C=M;O=D
Comment 5 Victor Campillo 2016-08-01 09:02:02 UTC
I also have the same issue after upgraded to 5.1.5.2 via ppa:libreoffice/libreoffice-5-1 on Xubuntu 14.04.

Everything works great in the previous version but now libreoffice is practically unusable, the rendering is quite slow and the CPU goes to 100% in the Xorg process.

I tried resetting the user profile but nothing changes. On the other hand, in my system the OpenGL option is disabled and if I try to enable it, Libreoffice crash at start.

My Libreoffice data is:

Version: 5.1.5.2
Build ID: 1:5.1.5~rc2-0ubuntu1~trusty1
CPU Threads: 8; OS Version: Linux 3.19; UI Render: default; 
Locale: es-ES (en_US.UTF-8); Calc: group

If there is any test I could run to provide more info, please let me know.

Meanwhile I will revert my system to branch 5.0

Best Regards.
Comment 6 Marqeaux 2016-08-03 21:44:52 UTC
I encounter the same behaviour since I got an update from LO 5.1.4. to 5.1.5. I encounter this problem on multiple Linux distro's and on multiple machines (x86 and x86_64). I tried somewhat everything to solve this, but was unsuccesful so far. Starting with a new, fresh profile doesn't do the trick, increasing the memory usage of Libreoffice doesn't show any improvement, and OpenGL was already disabled by default. This sluggish behaviour, which launches my CPU to 100% instantly is not only seen with Calc, but also with Base. Both are practically unusable at this moment.

When starting up LO you see the start centre blink three times, and every time you hit the menu with the mouse pointer, the whole menu blinks again. Trying to scroll through a Calc or Base document makes it horribly slow.

It looks like there's something changed in the way the screen is rendered when in LibreOffice. LO 5.1.4 was working like a charm, but since the update to 5.1.5 a few days ago it totally went the wrong way.

I hope this is fixed very soon. I need LibreOffice for my work, and at this point I just can't do much with it.
Comment 7 Björn Michaelsen 2016-08-03 22:27:35 UTC
(reports so far are about 5.1.5.2 which is in the ppa)

Does this happen with LibreOffice as provided from libreoffice.org too?

Also please be specific: "multiple Linux distros" doesnt help -- listing them (and the architecture, e.g. amd64, i386) does.
Comment 8 Pedro 2016-08-04 08:25:48 UTC
(In reply to Marqeaux from comment #6)

> I hope this is fixed very soon. I need LibreOffice for my work, and at this
> point I just can't do much with it.

Have you tested disabling OpenGL as suggested in comment #4 ? Or testing version 5.1.5.2 downloaded from libreoffice.org as suggested in comment #7?
Comment 9 Victor Campillo 2016-08-04 10:49:57 UTC
(In reply to Pedro from comment #8)
> 
> Have you tested disabling OpenGL as suggested in comment #4 ? Or testing
> version 5.1.5.2 downloaded from libreoffice.org as suggested in comment #7?

If you read again the comment of Marqeaux, it says that the OpenGL option is disabled by default so no need to test disabling it.

I just tried the deb package downloaded from libreoffice.org and the behavior is the same as mentioned earlier.

My system is Xubuntu 14.04 x86_64, kernel 3.19.0-65.
Comment 10 Pedro 2016-08-04 11:12:43 UTC
(In reply to Victor Campillo from comment #9)
> (In reply to Pedro from comment #8)
> > 
> > Have you tested disabling OpenGL as suggested in comment #4 ? Or testing
> > version 5.1.5.2 downloaded from libreoffice.org as suggested in comment #7?
> 
> If you read again the comment of Marqeaux, it says that the OpenGL option is
> disabled by default so no need to test disabling it.

You are right. Apologies for not noticing.
 
> I just tried the deb package downloaded from libreoffice.org and the
> behavior is the same as mentioned earlier.
> 
> My system is Xubuntu 14.04 x86_64, kernel 3.19.0-65.

Instead of reverting to ppa 5.0 wouldn't it make more sense to manually install 5.1.4 from libreoffice.org?
Comment 11 Thomas Hackert 2016-08-04 11:55:15 UTC
Hello marty8, *,
thank you for reporting this bug :) However, I cannot reproduce it with
OS: Debian Testing AMD64
LO: Version: 5.1.5.1
Build-ID: 1:5.1.5~rc1-1
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: GL; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
(Debian's own version)

As I stumbled upon it after an Java™ update, would you do me a favour and test, if your Java™ version is recognized in LO (Tools - Options - LibreOffice - Advanced), please? And maybe try to enable / disable OpenCL (Tools - Options - LibreOffice - OpenCL) and retest it again, please? Does it change anything?
HTH
Thomas.
Comment 12 Victor Campillo 2016-08-04 11:57:20 UTC
(In reply to Pedro from comment #10)
> 
> Instead of reverting to ppa 5.0 wouldn't it make more sense to manually
> install 5.1.4 from libreoffice.org?

Yes, it has more sense and probably I will do it. The ppa option was because of laziness, with 3 commands I can change from version 5.1.x to 5.0.x and when required go back to 5.1.x to test if the issue is resolved.


Björn Michaelsen has changed the version of the issue from 5.1.5.1 rc to 5.0.5.2 release, maybe because there is not tag for 5.1.5.2?
Comment 13 Buovjaga 2016-08-04 12:27:02 UTC
Created version.
Comment 14 Victor Campillo 2016-08-04 12:37:45 UTC
(In reply to thackert from comment #11)

> As I stumbled upon it after an Java™ update, would you do me a favour and
> test, if your Java™ version is recognized in LO (Tools - Options -
> LibreOffice - Advanced), please? And maybe try to enable / disable OpenCL
> (Tools - Options - LibreOffice - OpenCL) and retest it again, please? Does
> it change anything?

Java is recognized without problem and the enable / disable of OpenCL makes no difference.

Maybe you can't reproduce the issue because of the version we use is 5.1.5.2 and not 5.1.5.1.
Comment 15 Thomas Hackert 2016-08-04 14:09:57 UTC
Hello Victor, *,
(In reply to Victor Campillo from comment #14)
> (In reply to thackert from comment #11)
> 
> > As I stumbled upon it after an Java™ update, would you do me a favour and
> > test, if your Java™ version is recognized in LO (Tools - Options -
> > LibreOffice - Advanced), please? And maybe try to enable / disable OpenCL
> > (Tools - Options - LibreOffice - OpenCL) and retest it again, please? Does
> > it change anything?
> 
> Java is recognized without problem and the enable / disable of OpenCL makes
> no difference.

O.K. Thanks for testing :)

> Maybe you can't reproduce the issue because of the version we use is 5.1.5.2
> and not 5.1.5.1.

Well, there is no 5.1.5.2 in Debian Testing now, and my parallel installed version
LO: Version: 5.1.5.2
Build ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5
CPU Threads: 4; OS Version: Linux 4.5; UI Render: default; 
Locale: de-DE (de_DE.UTF-8); Calc: group
(following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel/Linux)

is not slower than other parallel installed versions when either opening and changing an existing spreadsheet, or creating a new one ... ;) But maybe I did something wrong and/or my test files are not large enough or ... Would you be so kind to either provide us with a step by step instruction and/or test file, with which this bug is reproducible, please? And maybe the times needed to do step X with a former version and the time needed with 5.1.5.2 would be nice, too ... ;)
Sorry for the inconvenience
Thomas.
Comment 16 Björn Michaelsen 2016-08-04 14:40:47 UTC
Cant reproduce this with libreoffice 1:5.1.5~rc2-0ubuntu1~xenial1 from the LibreOffice fresh ppa on Ubuntu 16.04.

So far we have:
> reproduced on Mint 17.3 with unspecified version from fresh ppa (description)
> reproduced on Ubuntu 12.04 from fresh ppa (comment 2)
> reproduced on Ubuntu 14.04 from libreoffice-5-1 ppa (comment 5)
> reproduced on Xubuntu 14.04 with TDF build d/l from libreoffice.org (comment 9)

> NOT reproduced on Debian Testing with TDF build d/l from libreoffice.org (comment 15)
> NOT reproduced on Ubuntu 16.03 with 1:5.1.5~rc2-0ubuntu1~xenial1 (this comment)

Seems like this is an issue only on older distro releases (Ubuntu 12.04 and 14.04 bad, 16.04 and Debian Testing good) and happens both with builds from ppas as with TDF builds (comment 9).
Comment 17 Björn Michaelsen 2016-08-04 15:12:41 UTC
Does the problem persist if you force LibreOffice to use the generic X11 backend instead of the gtk one?

That is done with:
> pkill soffice && SAL_USE_VCLPLUGIN=gen libreoffice

Note this shuts down any LibreOffice you had running before starting again.
Comment 18 Caolán McNamara 2016-08-04 15:14:17 UTC
Is it gtk2 or gtk3, or both ?
If it is gtk2 what is the version of cairo ?
Comment 19 Michael Meeks 2016-08-04 15:24:15 UTC
100% CPU is an interesting problem for sure; sounds like a leaked Idle handler or somesuch; but - getting an:

strace -f -o /tmp/slog -s 256 -ttt soffice

(without soffice already running) might be interesting - just for a short period; well worth compressing the /tmp/slog =)

Thanks !
Comment 20 Victor Campillo 2016-08-04 16:14:29 UTC
(In reply to Björn Michaelsen from comment #16)
> Seems like this is an issue only on older distro releases (Ubuntu 12.04 and
> 14.04 bad, 16.04 and Debian Testing good) and happens both with builds from
> ppas as with TDF builds (comment 9).

I just tested it in one of my virtual machines and I can confirm that indeed the problem doesn't exist in Xubuntu 16.04 with libreoffice from the ppa.


Starting libre(In reply to Björn Michaelsen from comment #17)
> Does the problem persist if you force LibreOffice to use the generic X11
> backend instead of the gtk one?
> 
> That is done with:
> > pkill soffice && SAL_USE_VCLPLUGIN=gen libreoffice

I tried it but the problem persist.


(In reply to thackert from comment #15)
> Would you be so kind to either provide us with a step by step instruction and/or
> test file, with which this bug is reproducible, please? And maybe the times
> needed to do step X with a former version and the time needed with 5.1.5.2
> would be nice, too ... ;)
> Sorry for the inconvenience
> Thomas.

On my computer which is pretty fast (CPU Threads: 8, RAM: 16GB and solid state hard drive) the problem is easy to reproduce, just start Calc and every operation that need a redrawing of the window (scrolling, selection, resizing) slow down the whole system because the Xorg process consumes the 100% of one of my cores. There is no need to use a large file to see the issue, with a simple one is enough.


(In reply to Caolán McNamara from comment #18)
> Is it gtk2 or gtk3, or both ?
> If it is gtk2 what is the version of cairo ?

My distro Xubuntu is gtk2, I don't know about gtk3. Xubuntu 14.04 use libcairo 1.13.0~20140204-0ubuntu1.1
Comment 21 Commit Notification 2016-08-04 16:29:30 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=705d7597480b2307d7e4929ce9386d80ce2a0f16

Related: tdf#101213 speculative drop of CAIRO_OPERATOR_DIFFERENCE use

It will be available in 5.3.0.

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 22 Caolán McNamara 2016-08-04 16:37:31 UTC
I'm purely speculating here based on one of the things that changed from 5.1.4 to 5.1.5 in vcl. If this is reponsible then I'd sort of expect that the current master dailies also have the same problem. It'd be interesting if someone who has this problem could check todays daily from e.g.

http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/2016-08-03_23.43.46/ which is an non debugging build without the above speculative commit and report if it has the same rendering problems or not

If someone does have the problem with the old daily, then re-testing when the new daily with the above thing in place would be useful to see if its relevent.
Comment 23 Victor Campillo 2016-08-04 16:52:54 UTC
Created attachment 126594 [details]
Performance issue log
Comment 24 Victor Campillo 2016-08-04 16:53:32 UTC
(In reply to Michael Meeks from comment #19)
> 100% CPU is an interesting problem for sure; sounds like a leaked Idle
> handler or somesuch; but - getting an:
> 
> strace -f -o /tmp/slog -s 256 -ttt soffice
> 
> (without soffice already running) might be interesting - just for a short
> period; well worth compressing the /tmp/slog =)
> 
> Thanks !

Attached log file, the log just include open a file, scrolling up/down and close the file. I don't know if it's enough for debugging but since the log size grow pretty fast I didn't want to make an enormous file.

If there is any other thing I can provide to debug the issue, just tell me.
Comment 25 Victor Campillo 2016-08-04 17:20:07 UTC
(In reply to Caolán McNamara from comment #22)
> I'm purely speculating here based on one of the things that changed from
> 5.1.4 to 5.1.5 in vcl. If this is reponsible then I'd sort of expect that
> the current master dailies also have the same problem. It'd be interesting
> if someone who has this problem could check todays daily from e.g.

In the todays daily build I have the same issue, I will check tomorrow if your commit solves it.

Thanks to everybody that is taking care of this issue.
Comment 26 Victor Campillo 2016-08-05 07:04:42 UTC
I tried the last night build and the issue is solved, at least for me.

It would be good if anyone else who experiencing the issue test it.

Thanks for the fix.
Comment 27 Caolán McNamara 2016-08-08 09:04:56 UTC
that's my problem then if that's the solution
Comment 28 Caolán McNamara 2016-08-08 09:07:53 UTC
Fixed on master, gerrit reviews for 5-2 and 5-1 in gerrit queue
Comment 29 HansPL 2016-08-09 14:25:44 UTC
Reproduced VERY noticeably on Linux Mint Debian Edition x64 Mate with jessie-backports:  Version: 5.1.5.2  Build-ID: 1:5.1.5~rc2-1~bpo8+1
I do hope the fix gets in jessie-backports very soon!
Comment 30 Cor Nouws 2016-08-09 16:07:37 UTC
*** Bug 101414 has been marked as a duplicate of this bug. ***
Comment 31 Ron Johnson 2016-08-09 16:18:15 UTC
> Seems like this is an issue only on older distro releases (Ubuntu 12.04 and
> 14.04 bad, 16.04 and Debian Testing good)

I am affected on Xubuntu 16.04 with packages from TDF.

Any possibility that http://cgit.freedesktop.org/libreoffice/core/commit/?id=705d7597480b2307d7e4929ce9386d80ce2a0f16 will get merged into 5.1 and 5.2?

Thanks.
Comment 32 Buovjaga 2016-08-09 17:15:45 UTC
(In reply to Ron Johnson from comment #31)
> Any possibility that
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=705d7597480b2307d7e4929ce9386d80ce2a0f16 will get merged into 5.1 and
> 5.2?

Yes, the cherry picks were merged:
https://gerrit.libreoffice.org/#/c/27983/
https://gerrit.libreoffice.org/#/c/27984/
Comment 33 Commit Notification 2016-08-09 19:37:52 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e645c112cbcf442ac57901099cd644900ce9ec6c&h=libreoffice-5-2

Resolves: tdf#101213 drop use of CAIRO_OPERATOR_DIFFERENCE

It will be available in 5.2.1.

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 34 Commit Notification 2016-08-09 19:39:16 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d89abe0806947149eafbd9d7ce4b3095ec38b236&h=libreoffice-5-1

Resolves: tdf#101213 drop use of CAIRO_OPERATOR_DIFFERENCE

It will be available in 5.1.6.

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 35 Alvin Kho 2016-08-11 01:36:18 UTC
On 2016-08-08, I upgraded to LibreOffice 5.2.0~rc4-0ubuntu1~trusty2 via routine daily Software Updater on my machine (Ubuntu 14.04.5 LTS) and found a similar problem where LibreOffice Calc 5.2 was super slow opening and rendering even small .csv/.xls files (100 rows x 10 columns) and eating up huge CPU time.

I found this bug thread, tested http://dev-builds.libreoffice.org/daily/libreoffice-5-1/Linux-rpm_deb-x86_64@70-TDF/current/libreoffice-5-1~2016-08-10_10.14.06_LibreOfficeDev_5.1.6.0.0_Linux_x86-64_deb.tar.gz - and can confirm that in this daily build the problem is resolved.

I hope LibreOffice folks will fix this problem back on the LibreOffice 5.2 build for Ubuntu. Am long time user and big fan of LibreOffice. Thank you for all your help!
Comment 36 Buovjaga 2016-08-11 08:57:25 UTC
(In reply to Alvin Kho from comment #35)
> I hope LibreOffice folks will fix this problem back on the LibreOffice 5.2
> build for Ubuntu. Am long time user and big fan of LibreOffice. Thank you
> for all your help!

Thank you for the kind words. The fix will be in 5.2.1.

If you have some spare minutes now and then, you could do general testing as part of the QA team: https://wiki.documentfoundation.org/QA
Every fruitful testing effort you make means the developers have more time to spend on essential things.
Comment 37 Alvin Kho 2016-08-11 17:17:24 UTC
(In reply to Buovjaga from comment #36)
> (In reply to Alvin Kho from comment #35)
> > I hope LibreOffice folks will fix this problem back on the LibreOffice 5.2
> > build for Ubuntu. Am long time user and big fan of LibreOffice. Thank you
> > for all your help!
> 
> Thank you for the kind words. The fix will be in 5.2.1.
> 
> If you have some spare minutes now and then, you could do general testing as
> part of the QA team: https://wiki.documentfoundation.org/QA
> Every fruitful testing effort you make means the developers have more time
> to spend on essential things.

Thank you so much Buovjaga! Looking forward to 5.2.1 on Ubuntu 14.04
Comment 38 Jamieson C 2016-08-14 21:33:16 UTC
I just tested daily build
libreoffice-5-2~2016-08-11_08.34.56_LibreOfficeDev_5.2.2.0.0_Linux_x86-64_deb

All of the performance problems I observed in 5.1.5.2 are fixed in the daily build. Bravo! I look forward to 5.2.1 rolling out in the PPA.
Comment 39 Steve Edmonds 2016-08-16 04:44:42 UTC
Hopefully 5.1.6 will be rolled out to repositories for openSUSE soon as just struck the problem today after software update and no rollback to 5.1.4 in the repositories.
Comment 40 Aron Budea 2016-08-16 08:23:48 UTC
Steve, the next (and final) update to Still version 5.1 is expected much later, in October, see release plan at [1].

The next update to Fresh version 5.2 is expected in ~2 weeks, but 5.2.1.1 RC (which I believe contains the fix) is available right now at [2], or should be available on the download page as prerelease version soon, and can be installed in parallel without disrupting the existing installation as described at [3].

Hope this information helps.

[1] https://wiki.documentfoundation.org/ReleasePlan
[2] http://dev-builds.libreoffice.org/pre-releases/
[3] https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Comment 41 Alvin Kho 2016-08-16 15:42:15 UTC
FWIW, I tested http://dev-builds.libreoffice.org/daily/libreoffice-5-2/Linux-rpm_deb-x86_64@70-TDF/current/libreoffice-5-2~2016-08-16_10.32.27_LibreOfficeDev_5.2.2.0.0_Linux_x86-64_deb.tar.gz on Ubuntu 14.04.5 LTS and the slow rendering / recalcing problem seems to be resolved :) Thank you!
Comment 42 marty8 2016-08-16 17:20:02 UTC Comment hidden (no-value)
Comment 43 marty8 2016-08-17 00:17:04 UTC
Loaded version 5.2.1.1 and it is working perfectly with Linux Mint 17.3 Rosa.
Comment 44 pharmankur 2016-08-19 13:38:30 UTC
Created attachment 126908 [details]
Test File Contain Pivots , References, Formulas etc.
Comment 45 pharmankur 2016-08-19 13:42:45 UTC
Created attachment 126909 [details]
CPU Use while opening Performance_test.ods
Comment 46 pharmankur 2016-08-19 13:44:26 UTC
Tested with latest 5.2.0 on Linux mint 17.1 32 bit machine 4 GB RAM

Calc is taking too long to open, update and even entering values in single cell makes me to wait 3 mins for each entry.
Enclosing the file Performance_test.ods (just 2.6 mb size)

1) Try to open ---> it almost stalls while opening at about 45% (enclosed screenshot of CPU usage)
2) Once opened --> Try to update any value in column "L" from sheet "PSR Configuration" ... Press enter ... It will take another of your life to update.
3) Try to update pivote table from sheet "Pivot-PSR Configration_Update" ... your one more life long wait begins before calc unfreezes and become usable.

I remember to use same calc file like a flash since last 3 years. Libreoffice is getting more & more irritating and buggy.

Note - I have tried eveything from increasing memory allocation , disabling & enabling JAVA etc ... almost everything i could find solution on net ... but NOTHING WORKS and PROBLEM REMAINS.
Comment 47 Caolán McNamara 2016-08-19 14:38:02 UTC
pharmankur: See the whiteboard at the top of this bug for the targets in which this specific problem is fixed. 5.2.1 and 5.1.6 and 5.3.0.

Its not clear if this problem is your problem, if it is then failure in 5.2.0 is expected while 5.2.1 will be ok. If it is not your problem, which you can verify by testing the test-build as per comment #33, then file a new bug.

If your problem persists you can even help yourself by googling for bibisect and following the guide for it, with which you can narrow down when exactly your problem began.
Comment 48 m.a.riosv 2016-08-19 16:09:36 UTC Comment hidden (obsolete)
Comment 49 m.a.riosv 2016-08-19 16:13:07 UTC Comment hidden (obsolete)
Comment 50 pharmankur 2016-08-20 05:24:54 UTC
(In reply to Caolán McNamara from comment #47)
> pharmankur: See the whiteboard at the top of this bug for the targets in
> which this specific problem is fixed. 5.2.1 and 5.1.6 and 5.3.0.
> 
> Its not clear if this problem is your problem, if it is then failure in
> 5.2.0 is expected while 5.2.1 will be ok. If it is not your problem, which
> you can verify by testing the test-build as per comment #33, then file a new
> bug.
> 
> If your problem persists you can even help yourself by googling for bibisect
> and following the guide for it, with which you can narrow down when exactly
> your problem began.

Caolan: Will test with 5.2.1 and report back soon. Cann't find anywhere 5.1.6 & 5.3.0 as on today.
Comment 51 pharmankur 2016-08-20 05:38:53 UTC
(In reply to m.a.riosv from comment #49)
> Comment#46
> 
> First, recalculation and update of PTs it's quick with Win10x64 and 5.2.1.1
> a few seconds for a hard recalc and 2~3 seconds for PT update, but really
> slow 5.1.5.2
> 
> The file seems was created with excel.
> 
> There are:
> - a lot of direct format in some sheets from the end of data to the last
> column/row, making slow open and save. By other reports LibreOffice doesn't
> like to deal with a such huge amount of cells with direct format, at least
> up to 5.1.
> - Some conditional format, with some of them for a whole column.
> - Some VLOOKUP() search on a whole column, that with 5.1.5.2 is slow, I
> think because doesn't shortcut the calculation beyond of the last row with
> data, perhaps because there are direct formats up to last row.
> 
> I think it has nothing to do with this bug report.

riosv: My organisation have moved from MS Office to Libreoffice for more than 3 years. Thus original files might have been created in excel. But I have confirmed that the file is modified, updated and saved in .ods format using LO (for last 3 yrs) which was working very fine in LO itself not very long ago.
So there must be some problems in recent 'UPDATED' versions.

Regarding 'Lots of data' ; 'Direct formats' ; 'Vlookup in columns' ... This complexity level is very much expected in organisational environment use of spreadsheet. I have worked with more complex and bigger datasets which worked flawlessly in MS Excel. 
If such basic data / formats / pivot handling is not possible with calc or is a limitation of calc ... its a problem, very serious problem !
Comment 52 pharmankur 2016-08-22 06:56:31 UTC Comment hidden (obsolete)
Comment 53 pharmankur 2016-08-22 06:57:55 UTC
(In reply to pharmankur from comment #50)
> (In reply to Caolán McNamara from comment #47)
> > pharmankur: See the whiteboard at the top of this bug for the targets in
> > which this specific problem is fixed. 5.2.1 and 5.1.6 and 5.3.0.
> > 
> > Its not clear if this problem is your problem, if it is then failure in
> > 5.2.0 is expected while 5.2.1 will be ok. If it is not your problem, which
> > you can verify by testing the test-build as per comment #33, then file a new
> > bug.
> > 
> > If your problem persists you can even help yourself by googling for bibisect
> > and following the guide for it, with which you can narrow down when exactly
> > your problem began.
> 
> Caolan: Will test with 5.2.1 and report back soon. Cann't find anywhere
> 5.1.6 & 5.3.0 as on today.

Tested my file with 5.2.1 ---> 
1) Opening of spreadsheet takes very long time (no improvement)
2) Selecting, Dragging, Pivot Table refresh, have improved significantly... Thank you very much I am happy !
3) Entering the data in cell (which is referenced to other cells / formulas) is now instantaneous ! I am happy for this as well ... Thank you developers !
Comment 54 Aron Budea 2016-08-24 00:23:53 UTC
*** Bug 101680 has been marked as a duplicate of this bug. ***