Bug 56406 - FILEOPEN and close very slow on a particular .odt
Summary: FILEOPEN and close very slow on a particular .odt
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) Master
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
Keywords: regression
Depends on:
Reported: 2012-10-25 17:51 UTC by Terrence Enger
Modified: 2012-12-07 18:01 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

typescript of the slow session (10.09 KB, text/plain)
2012-10-25 17:51 UTC, Terrence Enger

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2012-10-25 17:51:50 UTC
Created attachment 69084 [details]
typescript of the slow session

I find that my build of a recent master is very slow opening and
closing the file available at <http://www.pitonyak.org/OOME_3_0.odt>.
This is Andrew Pitonyak's "OpenOffice.org Macros Explained OOME Third
Edition" revised 2012-10-01, a document of 587 pages.  Here are some
times in minustes:seconds for comparison ...

         LO-natty       Portable-LO    master
open     00:18          < 01:00        42:00
close    00:15          < 01:00        28:57

Note ...

(1) "open" is the time from double-clicking the file name in the open
    dialog or in the list of recent files until the prompt to enable
    macros.  "close" is the time from clicking the "X" in the title
    bar of LibreOffice until the LO display is cleared and the disk
    drive is silent.

(2) LO-natty is the version of LibreOffice provided with ubunty natty
    (11.04) 32-bit.

    Portable-LO is a download from portableapps.com, which identifies
    itself as Version (Build id da8c1e6), running on a WinXP
    box so locked down that all I am really confident saying is that
    it displays time-of-day with resolution only to the minute.

    master is commit id f1b6058, pulled 2012-10-13, configured as ...
    built and running on unbuntu 11.04 32-bit ...
        $ uname -a
        Linux cougar-natty 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 18:00:43 UTC 2012 i686 athlon i386 GNU/Linux
        $ gcc --version
        gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

(3) During the long intervals when local built LO was opening and
    closing the file, the CPU was used about 100% and there was no
    noticeable disk activity.

Usually my LibreOffice built with debugging symbols is noticeably
slow, but only about two or ten times as slow as the version from
ubuntu, I would guess.

I have not found an odf validator which will accept the file.  The best 
result is "HTTP Status 412 - Request body length exceeds the permitted 

Comparable but different bugs are ...
(*) 49848 "FILEOPEN: Worse-than Linear Performance Degradation 
    Opening Change-Tracked ODTs "
(*) Numerous bugs citing slowness with MS Word documents.

Because of the magnitude of the slowdown, I am filing this as a defect
rather than request for enhancement, and I am supplying keyword
"regression".  I look forward to hearing results from someone who has
built LibreOffice with parameters more like a distribution.

Comment 1 Joel Madero 2012-12-06 17:55:45 UTC
I cannot reproduce this. For me the file opens in about 25 seconds with LibO, marking as WORKSFORME. 

Can you try updating your master and opening it again? If you can reproduce still please reopen as UNCONFIRMED and I'll get someone to get a second opinion on this.

Thanks for reporting
Comment 2 Terrence Enger 2012-12-07 18:01:42 UTC
Thank you, Joel, for reminding me of this bug report in particular and
for the tremendous effort you have been making to triage bug reports.

I conclude that the slowness of my LibreOffice can plausibly be
attributed to configuration parameter --enable-dbgutil and the
resulting use of debug version of STL iterators.  I am setting
bug status to NOTABUG.

Some details, for those who might care ...

(*) With master commit af3030e (2012-12-05), the program took 42
    minutes to get as far as the dialog box "Enable macros", and
    closing the document and the program took 1 hour and 17 minutes.

(*) Looking at callgrind data from the first five hours or so of
    opening the file, I see ...

      - "inclusive" numbers for debug iterators add up to way more
        than the total cost.  I do not know how to extract the
        inclusive cost of a set of functions (i.e., without double
        counting the cost of references within the set).

      - Looking just at the "exclusive" cost of the couple of hundred
        most expensive functions, I see debug STL functions account for
        65% of all the cost to that point.  The classification of
        functions is my rough-and-ready guess based on the part of
        output from callgrind_annotate which fits within the width of
        my screen.