Openbenchmarking results of Libreoffice

I was curious about the increase of performance of libreoffice, so I head it to but I could not see any results.
I wonder where can I check performance of libreoffice to compare with other suites.
Here is a test of how long it takes to compress a file

A given test of how long it takes to convert a document or something

Can you edit your question to indicate the type of tests and results you might expect? I had a look at the site and apart from largely targeting hardware, rather than applications, I cannot see anything that would indicate how an application like LO would be tested e.g., how would a test of open document X, perform action Y, then Z, be conducted? A macro using the UNO / API? Does the vendor / tester have to provide the test suite? How is this standardised? Lots of questions, very few answers.

Here you have test of how long it takes to compress file.
Maybe how long it takes for the first time LIBO is open it. or a given document, spreadsheet or presentation.

Benchmarking studies are convenient but at the end it is all about personal preferences and personal demands.

I just can tell you my own approach: I had MS Office installed and installed parallel LibO (it was that time LibO 3.4) to test both systems against each other based on my needs and preferences. I found some elements in LibO which I did not like so much but there are also elements in MS Office which I don’t like. However, I suddenly recognized that I use LibO more often than MS Office and switch completely over to LibO saving all files by default in ODF format. I convert only to MS Office formats when a pdf-file cannot be used. Maybe 1% of files which I need to share I share in MS Office format and then in the formats without an x at the end.
Since I have my new PC, I only have LibO installed - no waste of time and money for MS Office. Additionally I have a portable version on a USB-stick for presentations for which I cannot use my own PC.

Additionally I write bug reports and enhancement request and enjoy when they become reality in a newer version.

By the way, did you ever write a bug report to MS and got a response?

Maybe this is an approach for you as well.

--------edit after 1st comment

@cheche - I had a look at the link you provided and looked also a the bug 39179

I opened in LibO on XP/SP3:

  • 50 page file (123kB): in 46.9 sec; bug report: 2 min
  • 119 page file (312kB): in 147 sec, bug report: 6 min
  • 17 page file with 1.5 MB: in 4 sec; the bug reports gives no indication on opening time

Test conditions:
Downloading the file on my desktop
LibO started
File>Open> selected file an hit ENTER

Why is the largest file opening in the shortest time?
Are there different docx versions included? What makes the 17 pages file so big (1.5MB)?
I have no answers.

Does this now mean that LibO is so much faster than the various version of the 3 family?
I don’t know because the CPU type is not reported and there is also no information what other programs are running in the background.

This means one has to consider many parameter in a benchmarking test and if one or the other parameter does not match with your configuration and machine, the test can be completely irrelevant. Therefore I just make a test on my own machine and decide on what I experience.

Maybe this is food for thoughts.

ok. I get your point but I am searching for data, not personal preferences. I thought that having a test suite that tell you if a new release get slower allows you to use profiling in a specific area like in this post

“Why is the largest file opening in the shortest time?” The largest file contains a 7.3MB OLE object and 723kB PNG, that together account for 95% of the file size. The linked bug appears to primarily be concerned with large numbers of footnotes and the effect this has on performance, with respect to the DOCX filter. Further detail about footnote processing in LO in this article. Related bug fdo#62656 has an even worse test document.

@oweng - Thanks for your explanations about the content of the files. This means that in a benchmarking also a standard file would be needed And import filters have an additional problem. Thus benchmarking is not easy, and I am happy about the way I decided for LibO, which I like a lot and will not go back to MS Office.

“This means that in a benchmarking also a standard file would be needed And import filters have an additional problem.” Yes. It becomes even more complicated as the ODF spec is changed moving forward. Using an ODF v1.2 Extended file (from today) in an ODF v1.3 compatible version of LO (in the future) will not necessarily be meaningful, other than generally speaking.

Thanks for the test example. It is about what I expected (a series of install, pre, test, and post scripts). I imagine this means the tests will likely need to either:

  • Run LO in headless mode, OR
  • Open a document with an auto-start macro that accesses the UNO API to perform the required GUI mode test actions.

Neither is going to be very indicative of UX but would probably be useful as a general metric. The developers may have similar tools for testing and performance checking, so it may be worth contacting them.

EDIT: Another issue that I have just noticed is trying to determine the particular test suite that would apply to LO. There is nothing in that list that relates to office suites or even general application processing. The test suites are mainly targeted at applications with direct performance bottlenecks e.g., audio encoding, file compression, mathematic computation, graphics rendering, etc. These types of utilities are relatively easy to test in a linear manner, by comparison with a large application suite such as LO. It would still be interesting to test LO, but also more challenging. is a start. Markus Mohrhard explain a bit futher those test Performance tests are now executed regularly in LibreOffice | moggi's blog about Libreoffice hacking