You are not logged in.
Hi,
I've updated to the recent LO 3.6.1, and have noticed, that the Calc is quite slow when manipulating with bigger data file.
I have about 5MB large ODS spreadsheet, in which I store various data.
Before on LO 3.5.* , it worked fast.
Now, it takes minutes to load or save the file at change. And I'm updating the file quite often per day.
When I was searching for an root cause, I've noticed, that only one CPU core is being in use by CPU process when loading/saving.
I believe, this migt be it, as I have laptop with 4 core CPU (i5) , and htop/top revealed only one working on 100% at the process of load/save.
I've tested it also on one another separate arch virtual pc, having only two CPU cores, and htop/top again revealed only one CPU core in use at 100%.
Did anybody else noticed the same behaviour pls?
Whether it's global issue, or what?
thx
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
I can confirm that version 3.6.1, is unusable here. It has still to come up with a file of 9.5MB after more than 5 mins.
Personally I have practically given up on LibreOffice anyway. It used to work _reasonably well until an upgrade in November last year. Since then it has been slower than syrup, and practically useless for my project. Seems it's decided to give up altogether.
Offline
Thanks for the confirmation.
I filled an bug at LO https://www.libreoffice.org/bugzilla/sh … i?id=54638
Further confirmations are welcomed.
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
@ 8472 , whaler :
Largest ods spreadsheet i have on my system is 150k, and with that one there are no problems.
Assuming there's no private data in it, maybe you could upload those big spreadsheets somewhere ?
Then other users can verify if they have the same problem.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
@ 8472 , whaler :
Assuming there's no private data in it, maybe you could upload those big spreadsheets somewhere ?
Then other users can verify if they have the same problem.
Good idea, but it's my collection of horse-betting formulas/algorithms, so it's out of the question
SO/OOo/LO have all been fast enough with smallish spreadsheets. A couple years ago I experimented with Excel, which was _way faster, but as OOo was still workable, as well as preferable for other reasons (automatic formula completions, for one thing), I stayed with OOo and later LO. Since last November my spreadsheet adventures have been in a complete limbo; I hate the thought of switching to Windows...
Offline
@ 8472 , whaler :
Largest ods spreadsheet i have on my system is 150k, and with that one there are no problems.
Assuming there's no private data in it, maybe you could upload those big spreadsheets somewhere ?
Then other users can verify if they have the same problem.
Of course there are private data.
But I tested also an newly created spreadsheet, with duplicating the same data into about 10-20 columns, and afterwards duplicating the same data into about 1000-4000 rows. This creation worked fast.
Saving of these data took 37 minutes, but is only 330K large!
File is here: https://www.libreoffice.org/bugzilla/at … i?id=66797
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
Wow, just opening that file takes forever. Same as the OP, it pegs one core.
Offline
Wow, just opening that file takes forever. Same as the OP, it pegs one core.
I haven't tried to reopen it again. I had enough with the save which took 37min.
But, could you please try to create a similar test file of your own?
Just to exclude, that the possible bug was not inside of my file.
Last edited by 8472 (2012-09-07 15:45:41)
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
hmm, what exactly was in your file? I killed it before it opened completely. I created a new table of number (basically a multiplication table) 20 x 5000, total size is 660KB and it saves and opens just fine.
No formulas or anything in mine, though.
Last edited by Scimmia (2012-09-07 16:03:21)
Offline
it was just one word, multiple times in the same cell, like:
cell A1:
{
libreoffice
libreoffice
libreoffice
....
e.g. 20x
}
and this duplicated e.g. 20x4000
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
ok, I put the word libreoffice 20 times in one cell and duplicated it 20x5000. Save time was a bit under 3 minutes and file size is 205 KB.
Offline
Wow, klipper (KDE clipboard) didn't like that, it's still got a core pegged 5 minutes later.
Offline
ok, I put the word libreoffice 20 times in one cell and duplicated it 20x5000. Save time was a bit under 3 minutes and file size is 205 KB.
Yes, precisely, more data per one cell, e.g. multiple lines per one cell, and the time grows.
And actually, it muse have been more than 20 times per one cell before, I think , otherwise it wouldn't be that slow.
But I'm not anxious of opening that previous sample file again.
Anyway, I'm using a very, very much of multiple line data per one cell within my sheets.
I'm just testing it as well, based on your previous statement, and you're right, one line text, duplicated no matter how much, is fast.
But once you begin to use multiple lines per cell, e.g. my recent test with just two lines per cell, the time for load/save operations extends.
Anyway, the developers must have changed something. It worked much faster before each version, till it got this slug speed.
I'll post our findings into the bug report I opened.
@Scimmia, thanks for testing it.
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
You know, I realized that I just put a space in between the words and let it wrap instead of a hard return. I just tried it again and even duplicating it 20x1000 is taking far longer to save than the 3 minutes I quoted before. Libreoffice obviously don't like hard returns inside of a cell.
It just finished, about 20 minutes to save 65 KB. Lesson learned, do NOT use hard returns in Calc.
Last edited by Scimmia (2012-09-07 17:00:48)
Offline
Lone_Wolf wrote:@ 8472 , whaler :
Largest ods spreadsheet i have on my system is 150k, and with that one there are no problems.
Assuming there's no private data in it, maybe you could upload those big spreadsheets somewhere ?
Then other users can verify if they have the same problem.Of course there are private data.
But I tested also an newly created spreadsheet, with duplicating the same data into about 10-20 columns, and afterwards duplicating the same data into about 1000-4000 rows. This creation worked fast.
Saving of these data took 37 minutes, but is only 330K large!
File is here: https://www.libreoffice.org/bugzilla/at … i?id=66797
Yep, same issue here just totally pegs one cpu core at 100% and takes forever to open
Offline
You know, I realized that I just put a space in between the words and let it wrap instead of a hard return. I just tried it again and even duplicating it 20x1000 is taking far longer to save than the 3 minutes I quoted before. Libreoffice obviously don't like hard returns inside of a cell.
It just finished, about 20 minutes to save 65 KB. Lesson learned, do NOT use hard returns in Calc.
it's possible, that LO doesn't like it, as you've said.
But, once such function is at disposal, it should work without any bad "feelings" like you described
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline