| Summary: | FILEOPEN and close very slow on a particular .odt | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Terrence Enger <lo_bugs> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED NOTABUG | ||
| Severity: | normal | CC: | jmadero.dev |
| Priority: | medium | Keywords: | regression |
| Version: | 4.0.0.0.alpha0+ Master | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Attachments: | typescript of the slow session | ||
|
Description
Terrence Enger
2012-10-25 17:51:50 UTC
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.
|