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
(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
Portable-LO is a download from portableapps.com, which identifies
itself as Version 184.108.40.206 (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.
I cannot reproduce this. For me the file opens in about 25 seconds with LibO 220.127.116.11.alpha0, 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
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