Bug 125236 - Spreadsheet with lots of cells with multi-line contents is slow to save on Windows
Summary: Spreadsheet with lots of cells with multi-line contents is slow to save on Wi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.7.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Save File-Opening
  Show dependency treegraph
 
Reported: 2019-05-12 12:41 UTC by 8472
Modified: 2021-05-03 13:31 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
test file (329.23 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-05-12 18:43 UTC, Roman Kuznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 8472 2019-05-12 12:41:22 UTC
Description:
Hi,

since I don't work now with such calc files regularly as I did years ago, only recently I noticed a possible regression of the Bug 54638.
You can simply test the same sample attachment from that (Bug 54638).
Even if I reset the LO profile (remove the whole profile "~/.config/libreoffice/4/") and start from scratch, create the same content into a new ODF v1.2 extended (default) save file (which for an instance will have about 451KiB when saved), makes no difference, still takes very long.

Load:
Opening it on the more powerful (PC 1) takes about 16 seconds.
Opening it on the less powerful (PC 2) takes about 9 seconds.

Save:
Saving it on the more powerful (PC 1) takes about 5-6 minutes!
Saving it on the less powerful (PC 2) takes about 8-9 minutes!

While the duration of load in seconds is still tolerable, the SAVE in minutes isn't.
In both SAVE cases, only one CPU core is 100% utilized during all that time.


Thank you for checking it.

Steps to Reproduce:
Load or save the sample attachment from (Bug 54638).

Actual Results:
Takes minutes to save the sample.

Expected Results:
faster saving/export behaviour


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Affected LO calc versions tested & HW+SW details:
(PC 1)
CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (On-line CPU(s) list: 0-7)
RAM: 16GB
OS: Arch Linux
kernel: Linux 4.19.41-1-lts #1 SMP Wed May 8 15:58:57 CEST 2019 x86_64 GNU/Linux
LO Help\About:
	{
		Version: 6.2.3.2
		Build ID: 6.2.3-2
		CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: x11; 
		Locale: sk-SK (en_GB.UTF-8); UI-Language: en-US
		Calc: threaded
	}


(PC 2)
CPU: Intel(R) Pentium(R) CPU G3430 @ 3.30GHz (On-line CPU(s) list: 0,1)
RAM: 4GB
OS: Debian GNU/Linux 9.9 (stretch)
kernel: Linux 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64 GNU/Linux
LO Help\About:
	{
		Version: 5.2.7.2
		Build ID: 1:5.2.7-1+deb9u7
		CPU Threads: 2; OS Version: Linux 4.9; UI Render: default; VCL: gtk2;
		Locale: sk-SK (en_GB.UTF-8); Calc: group
	}
Comment 1 Roman Kuznetsov 2019-05-12 18:38:36 UTC
repro in

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 4cd4063f9cf531d1e948f27fcfd2eaed3d4a1a2d
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-08_23:08:36
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

open - 35 sec
save - I waited over 40 min and just close LO
Comment 2 Roman Kuznetsov 2019-05-12 18:43:11 UTC
Noel, may be you'll can look at this?
Comment 3 Roman Kuznetsov 2019-05-12 18:43:46 UTC
Created attachment 151324 [details]
test file
Comment 4 Noel Grandin 2019-05-13 11:31:56 UTC
With current master, loading takes approx 20s, and saving takes approx 10s
Comment 5 Roman Kuznetsov 2019-05-13 12:38:29 UTC
(In reply to Noel Grandin from comment #4)
> With current master, loading takes approx 20s, and saving takes approx 10s

It takes over 40 sec for opening and when I try to save I got over 15 min of freezing , then I killed LO

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

build from today (13.05.2019)
Comment 6 Noel Grandin 2019-05-13 12:42:39 UTC
It is vaguely possible that my recent commit

    https://cgit.freedesktop.org/libreoffice/core/commit/?id=349919440b1454eda2de783a0c3e6bd3bae4542b

makes a difference, since I tested in a tree with that commit.

Otherwise, I can't help you, sorry.
Comment 7 Roman Kuznetsov 2019-05-16 10:38:32 UTC
(In reply to Noel Grandin from comment #6)
> It is vaguely possible that my recent commit
> 
>    
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=349919440b1454eda2de783a0c3e6bd3bae4542b
> 
> makes a difference, since I tested in a tree with that commit.
> 
> Otherwise, I can't help you, sorry.

No, I don't see any changings in

Version: 6.3.0.0.alpha1+
Build ID: f665456cd0da35649bef179755be66c2aab290a7
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-05-16_02:11:30
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

it's a pity...
Comment 8 Noel Grandin 2019-05-20 06:54:06 UTC
This is perhaps now a windows- or locale- specific issue. Perhaps Roman can generate a flame graph of the bug on his machine?

https://randomascii.wordpress.com/2016/09/05/etw-flame-graphs-made-easy/
Comment 9 Noel Grandin 2019-05-20 06:54:52 UTC
Or use the Sleepy profiler
https://github.com/VerySleepy/verysleepy
Comment 10 Buovjaga 2019-05-21 11:22:09 UTC
(In reply to Noel Grandin from comment #8)
> This is perhaps now a windows- or locale- specific issue. Perhaps Roman can
> generate a flame graph of the bug on his machine?
> 
> https://randomascii.wordpress.com/2016/09/05/etw-flame-graphs-made-easy/

Telesto has mastered the Windows flame graph process
Comment 11 Telesto 2019-05-21 14:01:44 UTC
(In reply to Buovjaga from comment #10)
> (In reply to Noel Grandin from comment #8)
> > This is perhaps now a windows- or locale- specific issue. Perhaps Roman can
> > generate a flame graph of the bug on his machine?
> > 
> > https://randomascii.wordpress.com/2016/09/05/etw-flame-graphs-made-easy/
> 
> Telesto has mastered the Windows flame graph process

Mastered, is a slightly overstatement.. :-). Anyway, will post a flamegraph asap. Need to update my symbols only-build first.
Comment 12 Telesto 2019-05-26 06:58:41 UTC
No repro with
Version: 6.3.0.0.alpha0+
Build ID: 817e3447053d1a7465a5cf547b4eb39fc46b4d59
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded

Did something change the last 5 days?
Comment 13 8472 2019-08-30 18:04:28 UTC
Gyus, have just tested it with the 6.3.0 in my Linux, and the Save is working fast now, takes only seconds to save, not minutes anymore.
Could you please test it again, whether it's fixed for you too?
Comment 14 Buovjaga 2019-08-30 18:37:39 UTC
(In reply to Roman Kuznetsov from comment #3)
> Created attachment 151324 [details]
> test file

Saving on Win 10 takes about 4 minutes.
Saving on Linux takes 45 seconds.

Let's clarify summary and OS, then.

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 3e64065612acec2eb29aa21e2b515953422256d7
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-15_22:57:26
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded
Comment 15 Xisco Faulí 2020-03-25 15:05:04 UTC
Just for the record, the import time double after https://cgit.freedesktop.org/libreoffice/core/commit/?id=1e55a47e89a9d9d6cf9cb3993484022aaf2c097b
Comment 16 Buovjaga 2021-05-03 10:28:58 UTC
Saving takes 1min 14sec for me

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 9c930c4f3109d123c0831d0fcecf9c8b32e5bbc7
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: default; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded
Comment 17 Noel Grandin 2021-05-03 13:31:15 UTC
Testing on Windows10 with current master.

Load takes 22s for me
Save takes 14s.

I'm sorry, I can't repro this issue - possibly it has to do with language or spelling packs ?