Created attachment 151348 [details] A sample spreadsheet from https://ask.libreoffice.org/en/question/193663 The attachment opens longer than in 220 s on my system. Hard recalc takes only ~4 s - so it looks like it makes multiple unnecessary recalcs during load, instead of a single one after everything loaded?
I got a crash when try open file from attach in Version: 6.3.0.0.alpha0+ Build ID: 773ac3abbf8ab1343367e51b1774d2ee1f8c4f49 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded and LO takes over 1,5Gb of memory before crash Noel, may be you'll can look at this problem?
Is it possible that the links to non-existent external file data is part of the problem. The number of cells with a formula referencing that missing external file is huge, over one million.
Mike: Would a perf/Flamegraph help here or do you have already an idea how to fix this?
Created attachment 151376 [details] massif allocation report
So I can see that we are allocating 1G of string data to store formulas, and I can see where we are allocating them, but I don't know who is owning this memory and keeping it alive (since it is ref-counted stuff and passed around a lot)
(In reply to Julien Nabet from comment #3) > Mike: Would a perf/Flamegraph help here or do you have already an idea how > to fix this? I'm sorry for delay answering. I just found a performance problem, and reported it; I haven't looked (and have no plans to look) into this - acting as just a user here :-)
Eike, Markus, may be you'll can look at it?
In column G up to G5000 there are formulas like =IF($D5000="","",SUMPRODUCT(($A$2:$A$5000)=$D5000,$B$2:$B$5000)) Starting from G5001 for the rest of the entire (!) column there are formulas like =IF($E5001="","",SUMPRODUCT(('file:///media/u/Seagate Expansion Drive/files/Delivery Driving/Damgoode Pies/Damgoode_Spreadsheet_Preliminary005.ods'#$DG_DailyLog.$A$2:$A$5000)=$E5001,'file:///media/u/Seagate Expansion Drive/files/Delivery Driving/Damgoode Pies/Damgoode_Spreadsheet_Preliminary005.ods'#$DG_DailyLog.$AB$2:$AB$5000)) The data is only up to row 151 anyway.. If a 32 build crashes it's probably simply because it's out of memory.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/57df32e4bc12a3d67c44a1c544f7df21e1c8861e%5E%21 tdf#125254 Performance: A spreadsheet opens too slow, optimise listener It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b27755b704fa4866025f1ed6d26c0d43aafa3407%5E%21 tdf#125254 Performance: A spreadsheet opens too slow, part1 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/3c3a371c799d00475deb13b4c3e0a8860c7e4fb3%5E%21 tdf#125254 Performance: A spreadsheet opens too slow, part2 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/ecf456d067346d49d7e2a366434477fa7de06d8a%5E%21 tdf#125254 Performance: A spreadsheet opens too slow, part3 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This is about as good as I can get it, CPU-wise. The memory usage is a different storry - interning doesn't work, the formulas are all different, so the only way to improve it would be to change the import process to compile the formulas as it goes, which is a bigger change than I feel comfortable making.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/787525a314de9c8178d0fedcd71ddbd08ec41a55%5E%21 tdf#125254 Performance: A spreadsheet opens too slow, NameSpaceEntry It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
in Version: 6.4.0.0.alpha0+ Build ID: fe855eda54faf6196ad9dea12d8dc090b6d6c1da CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded it takes real 1m17,324s user 1m35,619s sys 0m5,378s while in Version: 6.2.6.0.0+ Build ID: 1914932e2fd0598508823464765f3b1ac31236a1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded it takes real 4m45,230s user 5m3,957s sys 0m6,401s so there is a nice improvement here...
Created attachment 165238 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today (49c8656eaf18dbbcfdcfb178c9407ea61c206ec4) + gen rendering I don't know if there's an impact but because of the bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965247, I had lots of: addr2line: DWARF error: could not find variable specification at offset 33966 So hope Flamegraph is correct.
Dear Mike Kaganski, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I'm not sure about "too slow" now in Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 3e544b6938ee509a4f6df4c2e2996d71ce072506 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded It opens the file for around 30 sec And LO still allocate ~1,7Gb of memory while opens the file
(In reply to Roman Kuznetsov from comment #18) > I'm not sure about "too slow" now in > > Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: 3e544b6938ee509a4f6df4c2e2996d71ce072506 > CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: > win > Locale: ru-RU (ru_RU); UI: en-US > Calc: CL threaded > > It opens the file for around 30 sec Agreed. Closing WORKDFORME. The memory consumption is unrelated, and wasn't initially the topic.