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.
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 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.
(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?
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
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.
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.
(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.
(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?
(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.
(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?
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.
(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?
Created version.
(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.
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.
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).
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.
Is it gtk2 or gtk3, or both ? If it is gtk2 what is the version of cairo ?
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 !
(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
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.
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.
Created attachment 126594 [details] Performance issue log
(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.
(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.
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.
that's my problem then if that's the solution
Fixed on master, gerrit reviews for 5-2 and 5-1 in gerrit queue
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!
*** Bug 101414 has been marked as a duplicate of this bug. ***
> 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.
(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/
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.
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.
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!
(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.
(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
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.
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.
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
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!
The Linux Mint update 5.2.0-4rc shows no improvement from the previous problems. Waiting patiently for an easily updated fix.
Loaded version 5.2.1.1 and it is working perfectly with Linux Mint 17.3 Rosa.
Created attachment 126908 [details] Test File Contain Pivots , References, Formulas etc.
Created attachment 126909 [details] CPU Use while opening Performance_test.ods
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.
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#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.
(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.
(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 !
(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, Pitot 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 !
(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 !
*** Bug 101680 has been marked as a duplicate of this bug. ***