Description: Sending a print job for a 400 paged document is rather slow Steps to Reproduce: 1. Open attachment 140185 [details] (bug 116068) 2. Print it to a PDF printer/XPS printer Actual Results: It takes +/- 90 seconds Expected Results: 25 seconds Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.1.0.0.alpha0+ Build ID: 5b87abe06da35ca3a11628674af23460349b439a CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-12_23:45:38 Locale: nl-NL (nl_NL); Calc: CL but not in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Not yet in 5.0.2, but already in 5.3.0 (tested on Win). I tried bibisection repos on Win, but they acted confusingly: sometimes they did not show any progress in the PDF printing dialog. So I can't say if the problem appeared in 5.1 or 5.2. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 28e8c3e28bf4944ecad23961602b9b1f72613d39 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on March 15th 2018
Might be a dupe (again, great!) of bug 112989.. A the dupes are mine already (keep forgetting about it)
I had 50-55 seconds Export as PDF and Print to PDF in LO 6.2+. Yes, slow. It's 15 seconds with 5.2. As you said, let's close as a dupe if Bug 112989 and check again should that one be resolved. You may use Personal Tags to track your own and realted bugs. *** This bug has been marked as a duplicate of bug 112989 ***
@Buovjaga Slightly opportunistic .. but I would love Noels perf magic in this area ;-). Not sure if it's within his expertise though.. because it's likely - based on bibisect - Harfbuzz related -> Opening the Print Preview Dialog -> Slow (not responding) -> Giving the print job to a virtual printer -> It can nearly see the dialog counts every page Yes: I'm biased like hell.. I'm the one complaining (I reported this bug and most of the duplicates of bug 112989) But the performance is quite horrific IMHO. And seems to me everybody would profit There quite something to gain here... IMHO
Created attachment 150585 [details] Flame Perf Graph for opening Print Dialog (CTRL+P)
Created attachment 150586 [details] Flame Perf Graph when giving the print command
(In reply to Telesto from comment #5) > Created attachment 150585 [details] > Flame Perf Graph for opening Print Dialog (CTRL+P) Looks like you are using ETW for those graphs (perf would be on Linux). Are you using a master build without debug symbols (you don't mention the version)? Asking because the traces have <itself> at the top and all kinds of "missing". I assume the only way to have one would be to build it yourself with --enable-symbols. Symbols for release builds should be in the symbol server. I once tried to get symbols set up with ETW, using UIforETW, but did not succeed. If you manage to get them working, please document the steps in the QA/BugReport/Debug Information wiki page, because ETW is a powerful tool. I used this blog as a source of information, when I messed around with ETW: https://randomascii.wordpress.com/2016/09/05/etw-flame-graphs-made-easy/
it takes real 6m48,663s user 6m41,552s sys 0m2,257s in Version: 6.5.0.0.alpha0+ Build ID: fb1eac64df88baae9f211d052793773686c0e180 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
PDF export performance problem reported in bug 116400
185 seconds with Versie: 6.5.0.0.alpha0+ (x64) Build ID: 42a1a1c6b91907f81e15066ffab219411f18c4db CPU-threads: 4; Besturingssysteem: Windows 6.3 Build 9600; UI-render: GL; VCL: win; Locale : nl-NL (nl_NL); UI-taal: nl-NL Calc: CL 175 seconds with Version: 5.3.0.3 Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: CL and 25 seconds with (old Layout Engine) Version: 5.3.0.3 Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: old; Locale: nl-NL (nl_NL); Calc: CL
Xisco, Telesto: can you shed light on why you disagree with the status?
Same reason I created all those reports and duped them to bug 112989. The new text layout engine removed the shortcuts for latin script which causing a regression from User POV. Printing and exporting Latin documents is terrible slow compared to LibreOffice 5.3 with the Old engine See bug 112989 comment 24: "Any meaningful comparison should use Arabic, Indic or other complex scripts. The old layout engines had a shortcut for Latin and similar scripts that did very simplistic and fast layout, the new engine does not have such shortcuts in principle. This is not to say our text layout is sub-optimal, it is very sub-optimal actually, but that is not a regression. It has always been sub-optimal, we were just lying by handling Latin in a special way." https://wiki.documentfoundation.org/Development/Budget2018 under the heading Text layout performance "Our text layout performance is abysmal, all over the code base it is assumed that shaping text is cheap and we can do it over and over again. Want to measure the text? Shape it and discard the output afterwards. Want to measure part of the same text? Shape again. Want to find line breaks? Shape again. Want to finally draw it? Shape again. This might have been cheap for Latin script in the olden days when all we did is query font cmap table and put glyphs next to each other, which is not the case anymore and never been the case for more involved scripts. We need to work on this, and there are many possibilities; retaining shaping results much longer, improving the wasteful OutputDevice API, caching etc."
(In reply to Telesto from comment #12) > Same reason I created all those reports and duped them to bug 112989. The > new text layout engine removed the shortcuts for latin script which causing > a regression from User POV. Printing and exporting Latin documents is > terrible slow compared to LibreOffice 5.3 with the Old engine But why disagree with duping to bug 116400?
(In reply to Buovjaga from comment #13) > (In reply to Telesto from comment #12) > > Same reason I created all those reports and duped them to bug 112989. The > > new text layout engine removed the shortcuts for latin script which causing > > a regression from User POV. Printing and exporting Latin documents is > > terrible slow compared to LibreOffice 5.3 with the Old engine > > But why disagree with duping to bug 116400? Valid point. Mainly because main bug report got closed as fixed and Xisco asked to check the duplicates and set it to unconfirmed if still present. And bug 116400 comment 0 is talking about a difference between 6.0.0.0.alpha0 and LibreOffice 6.0.2.1. which is clearly not the case. --- The performance is still major problem, IMHO. Text layouting quite fundamental for text editor. The current implementation is immensely expensive for productivity Waiting time (PDF export/ printing), costs (electricity) and the environment. Still hoping for a tender addressing this
I do believe this might have the same root cause as bug 116400. @Julien, would it be possible to have a perf chart so we can compare both ?
Created attachment 156709 [details] perf flamegraph (second dialog opening, printing to generic printer) Here's a Flamegraph on pc Debian x86-64 with master sources updated today (enable-symbols). There's also the first opening of printing dialog which is slow, I'll retrieve another Flamegraph for this.
Created attachment 156710 [details] perf flamegraph (first print opening dialog) Here's the Flamegraph when opening print dialog first time
Putting it to NEW
The document here isn't ideal.. has perf flaws on its own *** This bug has been marked as a duplicate of bug 133685 ***