| Summary: | FILEOPEN/FILESAVE extremely slow on large sheets | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Barna <doki24> |
| Component: | Spreadsheet | Assignee: | Barna <doki24> |
| Status: | NEW --- | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | CC: | doki24, dshimer, iplaw67, jmadero.dev, pje335-lo, suokunlong |
| Version: | 4.0.2.2 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=36779 | ||
| Whiteboard: | perf | ||
| i915 platform: | i915 features: | ||
| Attachments: | testcase | ||
|
Description
Barna
2013-04-19 23:42:51 UTC
To do anything about this problem we need a test file showing the issue. Without test files it is impossible to work on performance problems. Marking as NEEDINFO, get us a test case and set to UNCONFIRMED and we will investigate Created attachment 78289 [details]
testcase
Loading on my Macbook Pro to around 3-4 min I don't think this is to long because the file is very big. Wen trying to open with Apple Number it crasht opening the file toke 1GB of my ram saving the file into .xls format toke 3-4 mintis BUT it toke 99,9% of my CPU and !,5 GB of ram! So if some one has a les powerfull CPU or less ram it will take way longer. Version: 4.1.0.0.alpha0+ Build ID: fd179c5f308a0a611bc2b5a479e28ff3ced7964 (21 apr) os: mac osx 10.8.3 system: macbook Pro ram: 4GB cpu: 2.5 GHZ in core I5 Another observation: I tried to save the test file to an external HDD. During all the so called saving process, the outside HDD only worked in the last 1-2 seconds. All other work is done in the memory before writing any byte to the file. I'm not a C++ expert so I don't understand much from the source code, however I write programs in Delphi and experienced similar problems when working with automatically refreshing data: huge refresh-loops launched when a new item is added to the database to be refreshed. Probably something similar is happening here, since the sample database has many formulas. If their values are recalculated every time a new cell is added (or changed) during loading, it might cause severe speed problems and huge memory usage exponentially related to the amount of formulas. However it does not have any sense to do a cell-value refreshing before saving. Maybe it would be worth if somebody who is somewhat experienced in editing LibOffice code to check that out. If that's the problem, I would have some general ideas how to make cell-value refreshing (and thus loading) way faster. However I would need someone knowing C++ language to set it into practice... A potentially helpful new finding with the same file: If autosave is switched on, it is faster compared to clicking the save button. However the progress bar behaves weird: it progresses to about 90% quite normally, then it goes back and forth between 90 and 95%, then progresses to between 95 and 98%, going back and forth again in this range, then progressing to 99%, where I see no "going-back-and-forth", however I cannot exclude that, since the progress bar waits for several minutes in this position right at the right border of my screen. It seems as if somewhat would be performed several times at the end of the saving process, slowing it down quite a lot. I'm using LO 4.0.2 shipped with Ubuntu 13.04. I don't have any problem opening the attached file with 107 sheets. It opened in less than 2 minutes. Laptop: Acer Travelmate 4740 Ram: 2GB OS: Ubuntu 13.04 (In reply to comment #7) > I'm using LO 4.0.2 shipped with Ubuntu 13.04. > I don't have any problem opening the attached file with 107 sheets. It > opened in less than 2 minutes. When I saved this sample file in .ods format I observed the issue from comment 6 (which I have also seen in my large files): The progress bar goes to around 90% quickly, flutter around for a while, then goes to about 98%, stays unchanged for a long time, then vanishes. It's also worth noting that there is a period of time between when the progress bar vanishes and calc is usable after the save. It appears there is some processing happening after the progress bar vanishes that should be covered by the progress bar. A logging feature that records the state of the save with every progress bar change could: 1) Provide information to produce a smoother progress bar display, which would make it less likely for users to think that calc has hung. The fluttering, pause at 98%, and the unresponsive period after the bar vanishes are all worrisome as a user. 2) Give some hints about which parts of the save are unexpectedly slow (from the view of the original progress bar implementer) and might suggest areas to consider for performance improvements. Adding self to CC if not already on |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.