Bug 59882 - FILEOPEN: 2x slowdown loading particular document with 112 page table
Summary: FILEOPEN: 2x slowdown loading particular document with 112 page table
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) rc
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Keywords: perf, regression
Depends on:
Reported: 2013-01-26 02:06 UTC by webofht-libreofficebugs002
Modified: 2015-12-15 11:06 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:

well, caching results doesn't help one bit (4.75 KB, patch)
2013-02-12 14:53 UTC, Caolán McNamara

Note You need to log in before you can comment on or make changes to this bug.
Description webofht-libreofficebugs002 2013-01-26 02:06:09 UTC
Problem description: In LibreOffice, it takes more than a minute to open a particular file. (LibreOffice stops responding.) However, it takes a few seconds to open the same file in LibreOffice

Steps to reproduce:
1. The operating system used is Linux debian 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686 GNU/Linux.
2. The LibreOffice versions involved are:
- LibreOffice Version (Build ID: 2ef5aff) (LO3.6.4.3)
- LibreOffice Version (Build ID: 408fe71bd18616c467b3dcd7ab6756528ffcae2) (LO4.0.0.2)
3. The particular file is:


4. File -> Open -> (that document)

5. The file is just as big as 106.7 KB.

Current behavior:  LO4.0.0.2 stops responding for more than a minute when opening the particular file.

Expected behavior:  LO4.0.0.2 should open the particular file in a few seconds.

C. H. D.

Operating System: Debian
Version: rc
Last worked in: release
Comment 1 m.a.riosv 2013-01-26 02:52:17 UTC
Hi webofht, thanks for reporting.

Win7x64 Ultimate

about 25 seconds to load in any of them.

I do not know if is right. Except for the first paragraph, the rest of document it's all in one table.
Comment 2 Florian Reisinger 2013-01-26 14:30:59 UTC
About 13 sec here @ Win 7 with todays master...
No problems with MS Word 2010
Comment 3 Michael Stahl (allotropia) 2013-01-30 22:36:35 UTC
document contains one table over 112 pages which stresses Writer layout.

here it's about twice as slow in 4.0 than in 3.6...

2/3 of the performance difference are from this commit:

commit f4d20a400b5c06959fd5a362a350bb4d9a6e4bd1
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Sat Jul 14 21:21:15 2012 +0100

    Resolves: fdo#31821 use icu layout whenever possible
    because icu knows all about otf so we don't have to, which makes
    things its problem and not ours.
    This is the default route for all "ctl" languages already so if
    we suffer performance issues here we should try and fix that before
    just reverting

i wonder if this ICU stuff is slower just on this document or if it's
a more general issue; the ICU stuff does appear to create more
precise results anyway as seen in bug 59278
Comment 4 Michael Stahl (allotropia) 2013-01-31 12:33:54 UTC
now for a good surprise: the other third of the slow-down is due
to this patch (takes load time from ~13 to ~16 seconds here).

commit cb2536da21dcbd63aecdbc5ec45933afeff61772
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Thu Jul 26 17:47:21 2012 +0100

    bump liberation fonts to 2.0
    The 2.0 fonts are rebased on the google fonts and are now OFL and have a
    shed-load more glyphs in them. But note that current releases does not include
    Liberation Sans Narrow font because that couldn't be relicensed to OFL, so we
    retain the Narrow version from the old release.

because that changes some dmake module with non-working deps
i had to do bisect builds from scratch every time too :(
Comment 5 Caolán McNamara 2013-02-12 14:53:08 UTC
Created attachment 74688 [details]
well, caching results doesn't help one bit
Comment 6 Caolán McNamara 2013-04-16 10:31:45 UTC
One possibility is to reroute to harfbuzz instead of icu with dlsym stuff when its available and see if that layout impl performs better.
Comment 7 Khaled Hosny 2013-05-02 06:13:00 UTC
The slowness is not really because of the layout engine, it just made it worse. Inserting some printf's in the layout function shows a huge amount of text is being sent there like a million times. This seems to be something related to DOCX, as the document loads normally when converted to ODT.

I think it is a bug in DOCX code that just got worsened by slow layout engine.
Comment 8 Khaled Hosny 2013-05-02 06:19:53 UTC
There is exactly 422908 calls to layout() when opening the DOCX, as compared to only 6021 when opening the same file converted to ODT.
Comment 9 Khaled Hosny 2013-05-02 06:29:50 UTC
Opening both documents in headless mode, both seem to result in the same number of layout calls, roughly 440000, so it seems like we are loading the whole document at startup in case of DOCX.

But any way, there is some really inefficient code here laying the text out over and over again, probably to do some measuring.
Comment 10 webofht-libreofficebugs002 2014-02-02 01:32:07 UTC
(In reply to comment #9)
> But any way, there is some really inefficient code here laying the text out
> over and over again, probably to do some measuring.

Now with LibreOffice Version: (Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71), I open the file in five seconds or less.

Please close this issue. Thanks a lot.
Comment 11 Florian Reisinger 2014-02-02 07:34:58 UTC
Closed as by comment #10
Comment 12 Robinson Tryon (qubit) 2015-12-15 11:06:33 UTC
Migrating Whiteboard tags to Keywords: (perf)