Bug 65046 - libreoffice multithreading
Summary: libreoffice multithreading
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other Linux (All)
: medium enhancement
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-27 17:11 UTC by Rinat
Modified: 2016-11-26 16:31 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
The document on what I experience the slow down. (5.29 MB, application/vnd.oasis.opendocument.graphics)
2016-02-18 11:38 UTC, Michael Desnoyelles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rinat 2013-05-27 17:11:41 UTC
Problem description: Libreoffice uses only one CPU out of many when it counts ods documents, decompreessing them or in any documents which includes big table.

Steps to reproduce:
1. Create Spreadsheet
2. Fill many cells with data or formulas
3. save it, close office, and open file again

Current behavior:
it work very slowly, uses one CPU core at 100% percent, and doesn't use rest CPU cores. This behavior is in linux and windows systems.

Expected behavior:
Libreoffice will use all avalable CPU cores for counting and decompressing and that will make it more efficient.
              
Operating System: Ubuntu
Version: 4.0.3.3 release
Comment 1 Tom 2013-05-28 06:05:13 UTC
PC - at home
Windows 7 x64 Home premium
Celeron E3300 2.5 GHz 2 cores
3GB ram

PC- at work (there is over 150, I can sit and work on any of it but the one I use mostly)
Windows 7 x64 Professional
Core i3 2.6 GHz 4 cores
4gb Ram

Laptop
Ubuntu 12.04 x64 and Windows 7 x64 Home Premium
AMD APU E-450 1.6 GHz 2 cores
4Gb ram
(Interesting that on laptop in Ubuntu LibreOffice, also using one core, works faster even though the laptop is slower than my PCs)
Comment 2 Robinson Tryon (qubit) 2014-02-04 20:21:57 UTC
(In reply to comment #0)
> Problem description: Libreoffice uses only one CPU out of many when it
> counts ods documents, decompreessing them or in any documents which includes
> big table.
> 
> Steps to reproduce:
> 1. Create Spreadsheet
> 2. Fill many cells with data or formulas
> 3. save it, close office, and open file again
> 
> Current behavior:
> it work very slowly, uses one CPU core at 100% percent, and doesn't use rest
> CPU cores. This behavior is in linux and windows systems.
> 
> Expected behavior:
> Libreoffice will use all avalable CPU cores for counting and decompressing
> and that will make it more efficient.

Sounds like an enhancement request.
Severity -> Enhancement
Comment 3 Rpnpif 2014-07-11 07:25:07 UTC
All documents of some pages with images in writer are displayed very slowly when browsing.
Better display accelerating is welcome and multithreading would help greatly.

Firefox is a good example of rapid displaying code for long pages with images. Perhaps is it reusable or it give ideas ?
Comment 4 Michael Desnoyelles 2016-02-18 11:38:32 UTC
Created attachment 122763 [details]
The document on what I experience the slow down.
Comment 5 Michael Desnoyelles 2016-02-18 15:53:32 UTC
Intel Core Quad CPU Q6600 @2.40GHz
8GB Ram
Win 10 pro x64

Trouble with Draw that slow down cause only one core is working at 100%. De document is freezing for a minor changement.

I use many different type of fonts and some 3D spheres
Comment 6 René Genz 2016-08-14 19:28:58 UTC
Calc experiences slow downs with charts

To recreate:
- open Calc and create small data set: rows: 0 to 2 in 0.001 steps (approximately 2000 rows); 5 columns, all start at 0, but have different increments
- select all data points from data set
- create chart: Chart Type=XY (Scatter) -- Points and Lines -- [Finish]
- GUI of LibreOffice considerably slows down after creation of graph

If chart is out of view, GUI is very fast again.


In LibreOffice 4.4.4.3 (distributed with Fedora 22) moving view to different rows is:
- slow, if complete chart is in view
- slow, if chart is partly visible
- fast, if chart is not in view


At least with version 5.1.x drawing speed has improved for me.


In LibreOffice 5.1.5.2 (distributed with Fedora 24) and in LibreOffice 5.2.0.4 (tested with Flatpak on Fedora 24) moving view to different rows is:
- fast, if complete chart is in view
- slow, if chart is partly visible
- fast, if chart is not in view


It seems the whole chart is redrawn, if part of it is visible. Then again if more is visible.
This results in slow work with those charts.
Maybe the chart can be used from memory all time and only be redrawn, if its data has been changed?


On the same machine (Intel Core 2 Duo E8500 @ 3.16GHz; 4 GB RAM; GeForce 9500 GS) Microsoft Office 2010 32 bit on Windows 7 32 bit is fast in all 3 cases.

LibreOffice on Windows on the same machine shows the behaviour described above.
Comment 7 Alexander Alzate 2016-10-21 20:18:39 UTC
Resource usage in LO is still a problem and I think it should be taken as an important task.

I promote the usage of LO for all document generation in the enterprise I work, but performance is a recurrent problem.

By implementing a serious multithreading system into LO and a better resource usage policy the LO reception in corporation environment would be better IMHO.