Calc: Has anybody benchmarked various OS distributions for LO calc SPEED?

My hobby is stocks. Love LibreOffice calc. In examining 4000 stocks my daily calculation takes a couple or more minutes. I heavily use cell colors and the “Adjusting row height” takes a lot of time. Using LibreOffice 7.3 soon to upgrade, linuxmint17 soon to be LMDE.

How can I speed up the minutes of “Adjusting row height” without removing colors?

Which OS or common OS runs LO Calc the fastest? Has anybody benchmarked this?

Thanks! - Mike

How you use the cell colors: By manual (direct) formatting, or by pure cell styles, or by conditional formatting?

I use conditional color formatting, about 25 columns by 4000 rows.

Try upgrading: Search results for "speed" - The Document Foundation Wiki

Hi flywire: checking your reference, thanks for the URL. I seem to have a problem upgrading past 7.3 using my very very old LinuxMint 17.

By setting a fixed height of your rows.
I have done this for one of my sheets wit usually 1800 rows and several sheets and it speeds up loading the file.
.
In my case the length of strings could vary, so using a fixed row height has an impact on visibility, but color is independent.
.

I’d not expect big advantages here, with one exception: Compile LibreOffice yourself and for your used CPU. A binary distribution has to use a “common set” of instructions and a binary for your hardware may help. Gentoo is the only distro wich comes to my mind now.

That really will be slow…

Hi Wanderer: Thank You! I tried fixed row height a long time ago and it didn’t help. I will try it again.

Yeh, I was thinking Gentoo but I was afraid of messing it up. I was hoping someone would have benchmarked speed on different OSs.

Yep Zizi64, that’s for sure. Too bad I couldn’t color just the top and bottom 100 lines, but the total number of lines changes each day, usually around 3500. Yep, you are certainly correct, it will be slow… :slight_smile:

Hi Wanderer: I tried fixing/forcing the row height. Several attempts later results were all over the place from 17 seconds to 60 seconds, but one conclusion reached was fixing row height didn’t fix the problem. Maybe my problem isn’t “Adapt row height” so I will have to look at this more later, it is too late in the AM now. Thank You for your help.

Note that there is a really generic package, that indeed is expected to be considerably unoptimized: the one from TDF, which has no idea which OS/kernel and HW it will be actually run on. On the other hand, any distro-provided package (say, Ubuntu’s APT) would be built against the distro’s baseline CPU and libraries, with whatever optimizations available there. This would already provide great benefits in performance. And the last available piece is offered by the custom build, as @Wanderer suggests; I don’t know the actual ratio between the speed-up offered by the distro package against the generic TDF package, vs. the speed-up offered by custom build against the distro package; but my wild guess would be, that the latter would usually not be as significant as the former one.

Hi mikekaganski: Great Info! If I can repeat part of what you said: a package that comes from the distribution I am running (maybe using apt) might have been compiled in that distribution and might be actually faster than the package I downloaded from the package maintainer. I think that is what you said, correct me if I’m wrong. Thanks from MikeColley

I understand that when you say “the package maintainer”, you mean “the maintainer of the package of your distro”? You need to be specific. I explicitly mentioned TDF (The Document Foundation), the organization behind LibreOffice, and the generic packages offered from its website (libreoffice.org); but when you say “the package maintainer”, you may refer to the team that maintains e.g. Ubuntu packages ( “LibreOffice Packaging” team), which has an own PPA, which has some newer versions - but they, I expect, would be no less optimized (because that maintainer team builds them against the same/newer distro, its libraries and baseline, so would have the same / better optimizations).

I guess he will use the “original” packages of his Linux/Mint 17 based on Ubuntu as he wrote

… and I would not recommend to try a modern build on a 7 year old OS. May work as flatpack…

(Mint 17 seems to be based on Ubuntu 14.4 LTS and is not maintained anymore. As even Mint 20 “expires” this April 2025 I would recommend a newer version. Mint 22 receives LTS support until 2029, but I guess this will not include ALL applications.)

Ya Alls are correct. The way I got here was I was unable to just convert the system from LM17 to LM18 so I kept running LM17, and it served me very well until recently being unable to upgrade Firefox 122 and LO 7.3. This LM17 system worked very well for a very long time but now it is becoming incompatible with newer versions I use daily, but, they all still work good enough. I guess I will be starting a new system LMDE because there are fewer updates in LMDE. I really like a system that always works as this LM17 one has and doesn’t stop what I am doing because of an upgrade or an upgrade that changes or breaks stuff or adds one more stress just to upgrade. This is why I asked if anyone benchmarked LO calc so I could make an informed OS decision. In choosing LMDE I’m doing it in ignorance because nobody has benchmarked LO calc. Yes I know I’m crying “Oh Waaa” but I did ask first and I appreciate, really appreciate everyone’s contributions which helped a lot, THANK YOU ALL! :slight_smile: