Bug 77158 - libreoffice ODT Document freezing/halting/taking too much time while saving
Summary: libreoffice ODT Document freezing/halting/taking too much time while saving
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.5.3 release
Hardware: x86 (IA32) Linux (All)
: low major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-07 21:10 UTC by nwaldyd@yahoo.co.uk
Modified: 2015-11-04 16:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Problem File (22 bytes, text/plain)
2014-04-07 21:55 UTC, nwaldyd@yahoo.co.uk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nwaldyd@yahoo.co.uk 2014-04-07 21:10:38 UTC
Hello,

Always while saving the attached document, libreoffice becomes unresponsive/halts/freezes. Would you please tell me why?

Steps to Reproduce:

1) Open Document
2) Insert and then delete an space
3) Save The Document

Actual Results: 

libreoffice becomes unresponsive/halts/freezes

Build Date & Platform:

Linux localhost.localdomain 3.13.7-100.fc19.i686 #1 SMP Mon Mar 24 22:09:06 UTC 2014 i686 i686 i386 GNU/Linux


Additional Information:

I am running Fedora 19 and The following is my system info:

    description: Desktop Computer
    product: HP Compaq Elite 8300 CMT (C9G95LT#ABM)
    vendor: Hewlett-Packard
    width: 32 bits
    capabilities: smbios-2.7 dmi-2.7 smp-1.4 smp
    configuration: chassis=desktop cpus=4 family=103C_53307F 
  *-core
       description: Motherboard
       product: 3396
       
    
     *-cache:0
          description: L1 cache
          physical id: 4
          slot: CPU Internal L1
          size: 256KiB
          capacity: 256KiB
          capabilities: internal write-through unified
     *-cache:1
          description: L2 cache
          physical id: 5
          slot: CPU Internal L2
          size: 1MiB
          capacity: 1MiB
          capabilities: internal write-through unified
     *-cache:2
          description: L3 cache
          physical id: 6
          slot: CPU Internal L3
          size: 8MiB
          capacity: 8MiB
          capabilities: internal write-back unified
     *-memory
          description: System Memory
          physical id: 7
          slot: System board or motherboard
          size: 6GiB
        *-bank:0
             description: DIMM [empty]
             product: [Empty]
             vendor: [Empty]
             physical id: 0
             serial: [Empty]
             slot: DIMM4
        *-bank:1
             description: DIMM DDR3 Synchronous 1333 MHz (0.8 ns)
             product: PSD32G133381
             vendor: 8502
             physical id: 1
             serial: 00000000
             slot: DIMM3
             size: 2GiB
             width: 64 bits
             clock: 1333MHz (0.8ns)
        *-bank:2
             description: DIMM [empty]
             product: [Empty]
             vendor: [Empty]
             physical id: 2
             serial: [Empty]
             slot: DIMM2
        *-bank:3
             description: DIMM DDR3 Synchronous 1333 MHz (0.8 ns)
             product: 16JTF51264AZ-1G6M1
             vendor: Micron
             physical id: 3
             serial: 315AEDFB
             slot: DIMM1
             size: 4GiB
             width: 64 bits
             clock: 1333MHz (0.8ns)
     *-cpu:0
          description: CPU
          product: Core i7 (Fill By OEM)
          vendor: Intel Corp.
          physical id: e
          bus info: cpu@0
          version: 6.10.9
          serial: 0003-06A9-0000-0000-0000-0000
          slot: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
          size: 3400MHz
          capacity: 3900MHz
          width: 64 bits
          clock: 100MHz
          capabilities: x86-64 boot fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms cpufreq
          configuration: cores=4 enabledcores=4 id=0 threads=8
        *-logicalcpu:0
             description: Logical CPU
             physical id: 0.1
             width: 64 bits
             capabilities: logical
        *-logicalcpu:1
             description: Logical CPU
             physical id: 0.2
             width: 64 bits
             capabilities: logical
        *-logicalcpu:2
             description: Logical CPU
             physical id: 0.3
             width: 64 bits
             capabilities: logical
        *-logicalcpu:3
             description: Logical CPU
             physical id: 0.4
             width: 64 bits
             capabilities: logical
        *-logicalcpu:4
             description: Logical CPU
             physical id: 0.5
             width: 64 bits
             capabilities: logical
        *-logicalcpu:5
             description: Logical CPU
             physical id: 0.6
             width: 64 bits
             capabilities: logical
        *-logicalcpu:6
             description: Logical CPU
             physical id: 0.7
             width: 64 bits
             capabilities: logical
        *-logicalcpu:7
             description: Logical CPU
             physical id: 0.8
             width: 64 bits
             capabilities: logical
        *-logicalcpu:8
             description: Logical CPU
             physical id: 0.9
             width: 64 bits
             capabilities: logical
        *-logicalcpu:9
             description: Logical CPU
             physical id: 0.a
             width: 64 bits
             capabilities: logical
        *-logicalcpu:10
             description: Logical CPU
             physical id: 0.b
             width: 64 bits
             capabilities: logical
        *-logicalcpu:11
             description: Logical CPU
             physical id: 0.c
             width: 64 bits
             capabilities: logical
        *-logicalcpu:12
             description: Logical CPU
             physical id: 0.d
             width: 64 bits
             capabilities: logical
        *-logicalcpu:13
             description: Logical CPU
             physical id: 0.e
             width: 64 bits
             capabilities: logical
        *-logicalcpu:14
             description: Logical CPU
             physical id: 0.f
             width: 64 bits
             capabilities: logical
        *-logicalcpu:15
             description: Logical CPU
             physical id: 0.10
             width: 64 bits
             capabilities: logical

Best Regards,

Nestor Waldyd
Comment 1 nwaldyd@yahoo.co.uk 2014-04-07 21:55:33 UTC
Created attachment 97052 [details]
Problem File

The file can be downloaded from (160MB):

http://1drv.ms/1emWTau
Comment 3 Joel Madero 2015-05-12 16:57:41 UTC
This bug was incorrectly marked as NEW by reporter. It needs to be independently verified. Moving to UNCONFIRMED.
Comment 4 Buovjaga 2015-05-15 17:41:57 UTC
(In reply to nwaldyd@yahoo.co.uk from comment #2)
> Comment on attachment 97052 [details]
> Problem File
> 
> 
> https://drive.google.com/file/d/0B5KlecTUyUsHbW5yNWlqdV9qam8/edit?usp=sharing

No problem with saving here.

So you mean you have to kill LibreOffice? Or does it unfreeze by itself?

Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+
Build ID: 9de1d53a2ce3ee7036b4688b373db7b2235af4d9
TinderBox: Win-x86@39, Branch:master, Time: 2015-05-14_00:07:12
Locale: fi-FI (fi_FI)
Comment 5 Edmund Laugasson 2015-05-24 17:38:59 UTC
Using 64-bit Linux Mint Cinnamon 17.1 with 4.0.4-040004-generic kernel
LibreOffice version: 5.0.0.0.beta1
Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3
Locale: et-EE (et_EE.UTF-8)

It took a bit time but was possible to save. I would say the file is too big as pictures are too large. When I opened some picture properties (Format->Image) then I noticed that when to restore picture original size it was multiple times larger than the resized version in document. This means that picture will take same amount of RAM as it takes when it is at original size. To reduce the file size - the images must be resized with external program before adding them into Writer.

Certainly it depends also from the computer used for file opening. When opening .odt file it takes as much RAM as all the images will take simultaneously. Therefore it would be not so good idea to put all large-sized imaged into one .odt file.

Solution would be to resize and reduce images as much as possible - some bulk resize tool would be useful to use. Or use some cloud environment to handle it - the file is needed to share with somebody anyway - so the cloud storage will fullfill two conditions - file will be edited and also shared with appropriate people.
Comment 6 Edmund Laugasson 2015-05-24 17:49:55 UTC
Also increasing LibreOffice cache size may help, more information at https://help.libreoffice.org/Common/Memory
Comment 7 Asher 2015-06-29 19:29:15 UTC
Is the file really 160MB, what are you expecting?
Comment 8 David 2015-06-29 21:20:35 UTC
(In reply to Asher from comment #7)
> Is the file really 160MB, what are you expecting?


Yea, just try version 5.1 alpha to see what slow really is!
Comment 9 Joel Madero 2015-06-30 01:24:29 UTC
Please don't set bugs to CRITICAL without knowing what that means. This is not crtical - like it isn't even a bug. Saying "make it faster" is not a realistic bug report. A file that is 160 megs with huge pictures is going to take some time to open.

Moving to:
Major - I guess if it's freezing so much that it's unusable;
Low - this is a corner-case massive size file - of course it's going to be slow. The reality is this won't affect many users (as 160 meg writer files is incredibly rare).


If possible test against older versions of LibreOffice to see if this is a regression - testing against 3.3 would be nice: http://downloadarchive.documentfoundation.org/libreoffice/old/
Comment 10 Edmund Laugasson 2015-07-13 20:05:16 UTC
Test #1
*******
Test machine:
64-bit VirtualBox 5.0 r101573
OS: 64-bit MS Windows 10 Technical Preview build 10130
RAM: 6 GB
CPU: 2 cores Intel i5-3450; 3,1 GHz

This virtual machine runs in top of 64-bit Linux Mint 17.2

LibreOffice used in MS Windows:
LibreOffice 5.0.0.3 x64 (RC3)
ID: f79b5ba13f5e6cbad23f8038060e556217e66632
Locale: et-EE (et_EE.UTF-8)
Installed files:
LibreOffice_5.0.0.3_Win_x64.msi
LibreOffice_5.0.0.3_Win_x64_helppack_et.msi


Opening the file took 17 seconds.
Saving the file took 16 seconds. I just added one space and saved the file.

# # #

Test #2
*******
Test machine:
CPU: 4 core Intel i5-3450; 3,1 GHz
RAM: 16 GB
OS: 64-bit Linux Mint 17.2 with kernel 4.0.8-040008-generic

LibreOffice 5.0.0.3(RC3)
ID: f79b5ba13f5e6cbad23f8038060e556217e66632
Locale: et-EE (et_EE.UTF-8)

Opening: 2 seconds
Saving: 12 seconds

# # #

Results
*******
I do not see problems as the document is relatively large - 71 pages with lots of large images resized to small but will take same amount memory as they were large - I described it already previously. Navigator shows 243 graphic objects under images. There might be even more as the Navigator cannot count all graphics due to misspelled names.

I would say that any office suite will be slow with that file due to large amount of large images resized into small to view but inserted as large.

Suggestions
***********
1) Leave the document into MS OneDrive as is - everyone can access and download if needed.
2) Use some web-based image gallery to upload images and comment them as needed. such web galleries will resize images automatically as they needed.
3) Resize images as needed and then insert them into document.

About resizing
**************
E.g. 7,79 x 5,84 cm image is inserted as 21,59 x 25,40 cm (1280x960 and takes 630,9 kB). Resizing does not help - the image will take same amount of memory as it was in original size. Let's say you have 243 images and one image takes ~500 kB of memory. Then all graphics would take ~121,5 MB of memory.

I resized 1280x960 image to 300x225 with 85% of quality with GIMP 2.8.14 and got file size from 630,9 -> 22,2 kB. This is ~28,42 times smaller! But as you are using quite small size of these pictures, there is no point to insert them as large as they came from camera.

So very roughly calculation would say that you could have ~6 MB instead of ~160 MB for that file. Even if you will have a bit more then anyway it would be much better than have 160 MB...

So if you still consider it as a bug - please add your considerations so developers can take further steps.
Comment 11 Timur 2015-11-04 16:48:54 UTC
Since it's already Needinfo, I'll close this one as WFM. If you find it inappropriate, feel free to reopen, but with a response to comment 10.