Created attachment 90994 [details] the document which needs to be checked, and on its basis to improve opening of the doc format of files Problem description: the document is attached Steps to reproduce: 1. open the attached document and look at opening time 2. opening time five minutes Current behavior: opening time five minutes Expected behavior: has to open within several seconds Operating System: Windows XP Version: 4.3.0.0.alpha0+ Master
TESTING on Ubuntu 12.04.3 with LibreOffice Version: 4.3.0.0.alpha0+ Build ID: 164a8c409c2f070ee51ca4258585cf0c8579af51 TinderBox: Linux-rpm_deb-x86_64@46-TDF Branch:master Time: 2013-12-19_00:13:56 (In reply to comment #0) > Steps to reproduce: > 1. open the attached document and look at opening time > 2. opening time five minutes > > Current behavior: > opening time five minutes NOREPRO: Document opened for me in about 10 seconds. --- Joren - Please test on Windows
you write: TESTING on Ubuntu 12.04.3 with My Platform: Windows XP SP3 with last services pack, not linux
(In reply to comment #2) > you write: TESTING on Ubuntu 12.04.3 with > My Platform: Windows XP SP3 with last services pack, not linux I don't currently have a WinXP machine or VM here, so I tested on the system available to me and then cc'd one of the other QA Team members to help test on Windows: "Joren - Please test on Windows" Cheers,
Hello Test on windows 7/64 Proc: Intel(R) Core(TM)2 Duo CPU 3.06GHz RAM: 4.00 Go Version: 4.2.0.1 Build ID: 7bf567613a536ded11709b952950c9e8f7181a4a Version: 4.3.0.0.alpha0+ Build ID: f279acd3678d014d9d5dafe41971e0da4dec7b6c TinderBox: Win-x86@47-TDF, Branch:master, Time: 2013-12-13_23:25:16 Opening from scratch: 75 sec. (same with 4.2 & 4.3) Opening a document in doc format needs a conversion. The same document saved in odt format opens in a second on my platform. Regards Pierre-Yves
21 seconds to open on OS X 10.9, LO Version: 4.3.0.0.alpha0+ Build ID: 164a8c409c2f070ee51ca4258585cf0c8579af51 TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2013-12-19_00:12:55 Setting to new since this is indeed long. Can we get some dev input if this is expected and NOTABUG or if something needs to be fixed. -> NEW + OS: All.
Tagging as a performance-related issue. Whiteboard: perf
Created attachment 91339 [details] the document (6 pages) which needs to be checked, and on its basis to improve opening of the doc format of files Similar problem. 6 pages which come off seconds 16.
I can confirm: the first doc is loading on my win7 64bit i7, but takes 7min to open with LibO4.1.3.2) So as it seems, that there is already some work done on the performance. But in my eyes not enough - at least it just takes too long.
(In reply to comment #8) > I can confirm: the first doc is loading on my win7 64bit i7, but takes 7min > to open with LibO4.1.3.2) Ouch -- yes, sounds like a pretty classic performance issue. Dennis/Witalik - Could you please test with older versions (4.0, 3.6, 3.5, etc..) and see if the performance problems are a regression? Thanks! Whiteboard: (removing NeedAdvice)
tested attachment 91339 [details] with older releases under Win7x64 LibO 3.3.3 --> 3.6.7 takes 15 seconds to open (which is suboptimal too) LibO 4.0.4 --> 4.1.5 take 32 seconds to open probably a performamce regression started in the 4.0.x development (*) times to load may vary according to the power of the PC that was used. mine was a 5 years old laptop. I add Micheal Meeks to CC list since he's one of the "performance" experts.
As with all of these we need a callgrind trace of this opening under Linux with a build with debugging symbols installed thus: export OOO_EXIT_POST_STARTUP=1 export OOO_DISABLE_RECOVERY=1 valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin --splash-pipe=0 <my-test-file.doc> zip and provide the callgrind.12345.txt file - hopefully the slowness jumps out of that =) Thanks
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Unsure if this is sufficient, but according to a previous comment this couldn't in any case be reproduced in Linux. The following is a callgrind log from loading the second smaller document on OSX, where I can reproduce the issue on 4.4 master (external link due to large size): https://docs.google.com/uc?id=0B_soWPNbBZEVVmMxSW1KOVdOS3M&export=download
Possibly also of interest: For the second file (IDPZK_MODUL_2.doc), Save -> Reload -> Issue still present (so whatever the problematic formatting is, it appears to survive a round trip through .doc) Save as ODT -> Reload -> Save as .doc -> Reload -> Issue still present (ditto round trip through ODT, although the issue does not occur when loading from ODT) Set all text to one language -> Save -> Reload -> Issue no longer present Looking at the content.xml of the file as an ODT, <style:style style:name="T17" style:family="text"> <style:text-properties fo:color="#000000" style:font-name="Tahoma" fo:font-size="8pt" fo:background-color="#ffffff" loext:char-shading-value="0" style:font-size-asian="8pt" style:font-name-complex="Tahoma" style:font-size-complex="8pt"/> </style:style> ... <style:style style:name="T22" style:family="text"> <style:text-properties fo:color="#000000" style:font-name="Tahoma" fo:font-size="8pt" fo:language="en" fo:country="US" fo:background-color="#ffffff" loext:char-shading-value="0" style:font-size-asian="8pt" style:font-name-complex="Tahoma" style:font-size-complex="8pt"/> </style:style> ... <text:p text:style-name="P2">5.Салічна правда як правова памятка Франкської держави:загальна характеристика,регулювання речових прав.</text:p> <text:p text:style-name="Standard"> <text:span text:style-name="T17">Салічна</text:span> <text:span text:style-name="T22"> </text:span> <text:span text:style-name="T17">правда</text:span> <text:span text:style-name="T22">-</text:span> <text:span text:style-name="T17">це</text:span> <text:span text:style-name="T22"> </text:span> <text:span text:style-name="T17">збірник</text:span> <text:span text:style-name="T22"> </text:span> <text:span text:style-name="T17">записів</text:span> <text:span text:style-name="T22"> </text:span> <text:span text:style-name="T17">звичаєвого</text:span> <text:span text:style-name="T22"> </text:span> <text:span text:style-name="T17">права</text:span> <text:span text:style-name="T22"> </text:span> And so on. There appear to be long paragraphs of text where the language flips to EN and back between every word. Whether or not it's specifically language, it seems plausible that the slow loading speed may have something to do with this property dance. Setting the language doesn't seem to do anything to the larger document, so there may be something else going on there.
Results of similar analysis of the larger document: Roundtrip by Save in LO (as .doc or .docx) -> Reopen -> Issue not present Roundtrip by Open in Word (Mac, 2011) -> Save as .docx -> Reopen in Word -> Save as .doc -> Reopen in LO -> Issue still present Thus, comparing the OOXML saved by LO and Word to find the difference, it is quickly apparent that where LO writes in document.xml: <w:p> <w:pPr> <w:pStyle w:val="Normal"/> <w:spacing w:lineRule="auto" w:line="360"/> </w:pPr> <w:r> <w:rPr> <w:color w:val="000000"/> <w:sz w:val="28"/> <w:szCs w:val="28"/> <w:lang w:val="uk-UA"/> </w:rPr> <w:t>Рoздiл 1. Прaвoвi зaсaди тa мeхaнiзми мирoтвoрчoї дiяльнoстi ЛAД..............12</w:t> </w:r> </w:p> The same line of text written by Word instead goes: <w:p w:rsidR="000137C5" w:rsidRPr="004F22BB" w:rsidRDefault="000137C5" w:rsidP="000137C5"> <w:pPr> <w:spacing w:line="360" w:lineRule="auto"/> <w:rPr> <w:color w:val="000000"/> <w:sz w:val="28"/> <w:szCs w:val="28"/> <w:lang w:val="uk-UA"/> </w:rPr> </w:pPr> <w:r w:rsidRPr="004F22BB"> <w:rPr> <w:color w:val="000000"/> <w:sz w:val="28"/> <w:szCs w:val="28"/> <w:lang w:val="uk-UA"/> </w:rPr> <w:t>Р</w:t> </w:r> <w:r w:rsidR="0004393B" w:rsidRPr="004F22BB"> <w:rPr> <w:color w:val="000000"/> <w:sz w:val="28"/> <w:szCs w:val="28"/> <w:lang w:val="uk-UA"/> </w:rPr> <w:t>o</w:t> </w:r> <w:r w:rsidRPr="004F22BB"> <w:rPr> ... ...for a total of 42 <w:r> for one line of text, each with one or only a few characters in it. LO appears to be merging these segments on load, while Word does not. In total, in the version of the OOXML saved by LO there are 1102 <w:r>, while in the Word version there are 76028.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.