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 3.6.2.2 (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 ... --enable-symbols --enable-dbgutil --enable-crashdump --disable-build-mozilla --without-system-postgresql --enable-debug --enable-werror 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 maximum". 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. Terry.
I cannot reproduce this. For me the file opens in about 25 seconds with LibO 4.1.0.0.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 my screen.