Bug 139491 - FILEOPEN: Systematic very slow file loading on Calc
Summary: FILEOPEN: Systematic very slow file loading on Calc
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: GTK3 File-Opening
  Show dependency treegraph
 
Reported: 2021-01-08 10:12 UTC by mage99
Modified: 2022-08-26 03:36 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mage99 2021-01-08 10:12:20 UTC
Description:
Calc systematically takes ~30 seconds to open any file, including empty ones. Fresh install of Libreoffice 7.0.4.2 on Linux Mint 19.3 Cinnamon 5.4.0-60-generic.
I tested with and without Java & OpenCL, no difference.
No error message when launching via terminal, except the following warning:

Warning: failed to read path from javaldx

The problem does not occur when starting Calc itself, only when loading an already existing file.

The problem persists when starting libreoffice in Safe Mode.

When first starting Calc, then opening the file, the delay appears to be shorter (~20s) and some error messages appear:

(soffice:5580): Gtk-CRITICAL **: 11:07:41.656: gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed
Gtk-Message: 11:07:41.662: GtkDialog mapped without a transient parent. This is discouraged.
Gtk-Message: 11:07:45.252: GtkDialog mapped without a transient parent. This is discouraged.


Steps to Reproduce:
1. Create a new empty file "test.ods" and save it.
2. Close libreoffice.
3. Open "test.ods"

Actual Results:
Systematic ~30s loading time to open the file.

Expected Results:
Immediate file opening.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Ubuntu package version: 1:7.0.4_rc2-0ubuntu0.18.04.2
Calc: threaded
Comment 1 Roman Kuznetsov 2021-01-10 19:42:11 UTC
no problem in

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 96bafa464ebdbce3ef04bec9beae5e745bb37794
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL

only Linux (GTK3?) problem? Or may be only Mint's LO build problem?

Can you install LibreOffice from https://libreoffice.org/download and try repeat your problem?
Comment 2 mage99 2021-01-11 10:06:22 UTC
(In reply to Roman Kuznetsov from comment #1)

Exact same problem with a reinstalled version (7.0.4) from https://libreoffice.org/download.

> only Linux (GTK3?) problem? Or may be only Mint's LO build problem?

I do have the impression that it is indeed related to something like that. I had already the problem with the version 6.0 (which I hoped to solve by upgrading to 7.0) and some digging then pointed to LO trying to load a library with the wrong version.
Comment 3 Neela 2021-02-08 04:04:39 UTC
Thank you for reporting the bug. I can not reproduce the bug in 7.1.0.3
Comment 4 Neela 2021-02-08 20:27:23 UTC Comment hidden (obsolete)
Comment 5 Xisco Faulí 2021-02-09 10:20:21 UTC
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Comment 6 mage99 2021-02-09 13:42:28 UTC
(In reply to Xisco Faulí from comment #5)
> Thank you for reporting the bug. To be certain the reported issue is not
> related to corruption in the user profile, could you please reset your
> Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and
> re-test?
> 
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' if the issue is still present

I did a reset of the user profile, same issue.
Comment 7 Xisco Faulí 2021-02-15 17:52:07 UTC
Does you reproduce the issue if you launch LibreOffice from commandline with 'SAL_USE_VCLPLUGIN=gen' ?
Comment 8 mage99 2021-02-17 16:53:53 UTC
(In reply to Xisco Faulí from comment #7)
> Does you reproduce the issue if you launch LibreOffice from commandline with
> 'SAL_USE_VCLPLUGIN=gen' ?

Problem does not disappear when launching libreoffice with this parameter.

For some reason, the problem seems to now appear with Writer as well and not only Calc.

Is there a way to identify what is libreoffice trying to do when charging a document? Starting it from the terminal does not provide any information.
Comment 9 Tracey C 2021-07-24 18:27:34 UTC
I was able to reproduce the problem with a new, blank spreadsheet saved to odf format. I had noticed the problem when trying to open a spreadsheet that I've had for months and had loaded quickly up until a few days ago.

If I save the file in Excel 2007 format with .xlsx, close and re-open, it opens immediately as expected.

"top" showed nothing unusual


Steps to reproduce:
1. Open Libre Office Calc
2. Create a new spreadsheet. Save as odf.
3. Close Calc
4. Double click the file to open.
Result:
The blank spreadsheet takes a couple of minutes to open.

≻ time libreoffice ~/Desktop/test.ods
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx

________________________________________________________
Executed in  132.04 secs    fish           external
   usr time    3.44 secs  255.00 micros    3.44 secs
   sys time    0.51 secs   70.00 micros    0.51 secs


LibreOffice version: 7.1.4.2 10(Build:2)

System info:
Operating System: Solus 4.3
KDE Plasma Version: 5.22.2
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.3
Kernel Version: 5.13.4-189.current (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i7-7600U CPU @ 2.80GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 620
Comment 10 BogdanB 2021-12-03 18:10:52 UTC
No repro. Opening and closing in 3,29 seconds

real	0m3,290s
user	0m2,119s
sys	0m0,254s

Version: 7.3.0.0.beta1+ / LibreOffice Community
Build ID: 81b26582ed62db40e2be701ddefede7d8230d0d2
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Calc: threaded
Comment 11 Xisco Faulí 2021-12-13 12:05:11 UTC
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 12 Tracey C 2021-12-17 22:39:25 UTC
I'm no longer able to reproduce this bug with LibreOffice version 7.2.4.1 in either Calc or Writer


≻ time libreoffice ~/Desktop/test.ods
________________________________________________________
Executed in  633.43 millis    fish           external
   usr time   15.81 millis  816.00 micros   14.99 millis
   sys time   34.85 millis  144.00 micros   34.71 millis


≻ time libreoffice ~/Desktop/test.odt
________________________________________________________
Executed in  782.76 millis    fish           external
   usr time   48.75 millis   36.61 millis   12.13 millis
   sys time   27.91 millis    3.90 millis   24.02 millis

Thanks to all the developers that keep LibreOffice going :)
Comment 13 muesliflyer 2022-01-23 14:03:54 UTC
I am able to reproduce this observation.

LO appears to be waiting for a network response. Any suggestion how I could find out what LO is waiting for?

### Test 1

Laptop connected to my home network

Load times of empty LO documents more than one minute except for odt document.

empty.odt 3s
empty.odg 1m07s
empty.ods 1m04s
empty.odp 1m07s

Opening time of LO (without opening a file): less than 3s.

CPU load of LO is zero.

### Test 2 

Laptop is offline (disconnected from network)

Files load in less than 3 seconds.

### Test environment
* Home network with FritzBox and WD MyCloud NAS connected via SAMBA
* LibreOffice 7.2.5.2
* also LibreOffice 7.1.x
* Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz   2.81 GHz
* 16,0 GB
* Network: Gigabit Ethernet
* Windows 10 Home, 19043.1466

* Same results with two other laptops in my home network connected via WLAN
Comment 14 BogdanB 2022-01-23 17:57:47 UTC
If is waiting for a network to respond, I was seeing recently a bug solved about searching for files that are not local but on the network. Could you try 7.3 to see if the bug is solved there?...
Comment 15 muesliflyer 2022-01-24 20:44:35 UTC
Today, the wait is gone! All empty.xxx files open quickly within a few seconds. Very strange. No idea what is different today except that I rebooted my laptop.
Comment 16 muesliflyer 2022-01-25 18:20:08 UTC
I think I know what causes the delay:

My Windows default printer is a network printer connected to a Raspberry Pi that was off when it took LO a long time to start with opening a file. It seems that LO was waiting to access the printer during that long wait.

When the Raspberry Pi was on, LO started within a few seconds.

Details:

Windows default printer is: \\http://raspberrypi:631\Canon_MP550_raw

Raspberry Pi is off

Open empty.ods -> takes about one minute

Open File -> Printer Settings
Set printer to \\raspberrypi\SKG-Laser-2
Tap printer settings button
LO crashes -> that may be an unrelated problem.

Der Absturzbericht wurde erfolgreich hochgeladen.
Sie können den Bericht bald finden unter:
https://crashreport.libreoffice.org/stats/crash_details/f4f89c82-51ca-42d7-99bf-fc526d956cd9

Start Raspberry Pi

Open empty.ods -> opens fast

Open File -> Printer Settings
Set printer to \\raspberrypi\SKG-Laser-2
Tap printer settings button
LO crashes
Der Absturzbericht wurde erfolgreich hochgeladen.
Sie können den Bericht bald finden unter:
https://crashreport.libreoffice.org/stats/crash_details/0b11307d-407b-4b8d-9b20-2415a6436cd5

Set Windows default printer to "Microsoft print to PDF"

Shutdown Raspberry Pi

Open empty.ods -> LO starts fast

Set Windows default printer to \\raspberrypi\SKG-Laser-2

Open empty.ods -> LO starts fast

Open empty.ods -> LO starts after 24s

It seems that LO doesn't wait for \\raspberrypi\SKG-Laser-2 (= mounted via SAMBA?) as long as for \\http://raspberrypi:631\Canon_MP550_raw (= mounted via http). When default printer is "Microsoft print to PDF", there is virtually no wait.
Comment 17 QA Administrators 2022-07-26 03:29:43 UTC Comment hidden (obsolete)
Comment 18 QA Administrators 2022-08-26 03:36:48 UTC
Dear mage99,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp