At the end of your “non-answer”, there is a list of command links. One of these is more (only you as answer owner can see it). Click on it. A popup menu with “repost as comment” appears.
I wonder if it is an anti virus program scanning on load “unfamiliar” ODS files but not known file types like XLSX
ajlittoz: thanks. I had carelessly overlooked your earlier suggestion – my bad.
Antivirus: there’s no realtime antivirus running on this system other than Windows Defender, and this problem has surfaced only recently. Process monitoring shows no unusual processes running.
You might want to add an exclusion for .ods files, for how to, see Windows Defender Real Time Protection slowing file access on MS forums
After a reboot just now I double-clicked to open the file again with Sysinternals ProcExp running to try to catch anything else with a high CPU load during the open. But the file opened in just under 2 seconds. If opening it or any other spreadsheet goes too slowly again, I’ll try to measure then. I hate trying to track down these ephemeral problems. (Though of course I’d rather not have them to begin with.)
It’s back to slow-load. (!!) Monitoring with ProcMon shows that once opened, soffice.bin operates for 1.5 seconds and then shows no activity at all for about 12 seconds, when it becomes active again. What’s it waiting for? To be continued.
I’m still not at the bottom of this, but it’s happening with other spreadsheets. Just now a spreadsheet with static contents of 21 rows by 4 columns took over 35 seconds to load – three times! Has no one else encountered this?
Have you at least tried starting your spreadsheet with Defender disabled to see if it starts faster?
Or just exclude, probably, soffice.bin in Exclusions in Defender. Here is a link on how to exclude Thunderbird but you would just need to substitute soffice.bin for Thunderbird and User folder (%APPDATA%\libreoffice\4\user).
Thanks for the hint. I excluded soffice.bin for Windows Defender, but that had no effect: all the different sheets I tried still load quite slowly – the 21 x 4 sheet just took more than 50 seconds to load, another more than 30 seconds. AAARRRGH!
I’m going to add some basic information here before trying to analyze it further: I used Sysinternals Procmon to capture process events while I opened the spreadsheet first mentioned above, then looked at only soffice.exe and soffice.bin events. In one place after soffice.bin closed a Windows manifest file, there was a 27.7-second interval until the next soffice.* event (with 4,278 intervening non-soffice events), when three threads of soffice.exe exited within microseconds. After the last of those exited, there was an 8.3-second interval (1,492 intervening non-soffice events) until soffice.bin made a registry query… That’s a total of 36 seconds when neither soffice.exe nor soffice.bin was active.
As Calc opens the ODS file it tries to verify the availability of a printer, and calls on the print spooler spoolsv.exe to do it. spoolsv.exe goes looking for the printers it knows about, and in my household one of those is a recently installed wireless printer. spoolsv.exe blocks while making a network inquiry for the printer, and if that isn’t operating – if it’s not turned on – the process can take a long time.
If I save that ODS file as XLSX, the XLSX file opens immediately, but the ODS file still takes a long time. Can anyone explain that?
And is there some way to prevent soffice.bin from blocking while waiting for spoolsv.exe to do whatever it’s doing?
As Calc opens the ODS file it tries to verify the availability of a printer, and calls on the print spooler spoolsv.exe to do it. spoolsv.exe goes looking for the printers it knows about, and in my household one of those is a recently installed wireless printer. spoolsv.exe blocks while making a network inquiry for the printer, and if that isn’t operating – if it’s not turned on – the process can take a long time.
If I save that ODS file as XLSX, the XLSX file opens immediately, but the ODS file still takes a long time. Can anyone explain that?
And is there some way to prevent soffice.bin from blocking while waiting for spoolsv.exe to do whatever it’s doing?
I seem to remember there is a setting to constraint page size to those accepted by the printer. This is what may cause the delay: query the printer to get the installed tray sizes, wait for answer and possibly time-out.
For Writer, it is located in Tools>Options, LibreOffice Writer>Print but I can’t find an equivalent for Calc.
Since I seldom print, my network printer is nearly always offline but I never incur your nuisance.
Maybe see if in Tools > Options > LibreOffice Calc > General, under Input Setting if Use printer metrics for text formatting is ticked and untick it if it is.
The setting @EarnestAl suggests was already ticked off. I tried @ajlittoz’s suggestion, specifically Tools > Options > LibreOffice Writer > Print > Paper tray from printer settings. It was on, and I clicked it off. Since then, with the printer off, every spreadsheet I try opens immediately. I’ll try this for a while, and if it seems solid, then that would look like the answer.
Neither of those options would have been ticked in Safe Mode…
But I wasn’t clever enough to try that. 
Instead I slogged through analyzing Procmon output.
Please test if the issue had any relation with the Menu/Tools/Options/Load&Save/General - Load printer setting with the document.
That setting is off.
[Stuff happens. Then…] I haven’t been able to fix this systematically. It really appears to me that the delayed opening is because LO is searching for a printer that’s offline; that appears to be a good tip. But I can’t find (all) the places to tell LO not to bother with that, so it’s still slow unless that printer is online. Can someone help me find all those places and forcibly tell LO not to block while waiting to gather all the parameters for an offline printer?