Bug 116399 - Sending a print job for a 400 paged document is rather slow
Summary: Sending a print job for a 400 paged document is rather slow
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Print
  Show dependency treegraph
 
Reported: 2018-03-14 11:42 UTC by Telesto
Modified: 2020-01-21 12:42 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Flame Perf Graph for opening Print Dialog (CTRL+P) (57.60 KB, image/png)
2019-04-07 20:32 UTC, Telesto
Details
Flame Perf Graph when giving the print command (78.29 KB, image/png)
2019-04-07 20:49 UTC, Telesto
Details
perf flamegraph (second dialog opening, printing to generic printer) (157.52 KB, application/x-bzip)
2019-12-20 22:44 UTC, Julien Nabet
Details
perf flamegraph (first print opening dialog) (91.44 KB, application/x-bzip)
2019-12-20 22:50 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-03-14 11:42:02 UTC
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
Comment 1 Buovjaga 2018-03-15 19:39:18 UTC
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
Comment 2 Telesto 2018-03-16 08:37:27 UTC
Might be a dupe (again, great!) of bug 112989.. A the dupes are mine already (keep forgetting about it)
Comment 3 Timur 2018-06-14 12:20:15 UTC
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 ***
Comment 4 Telesto 2019-04-06 17:25:40 UTC
@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
Comment 5 Telesto 2019-04-07 20:32:30 UTC
Created attachment 150585 [details]
Flame Perf Graph for opening Print Dialog (CTRL+P)
Comment 6 Telesto 2019-04-07 20:49:22 UTC
Created attachment 150586 [details]
Flame Perf Graph when giving the print command
Comment 7 Buovjaga 2019-04-08 05:21:12 UTC
(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/
Comment 8 Xisco Faulí 2019-12-18 14:21:28 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2019-12-18 14:54:38 UTC
PDF export performance problem reported in bug 116400
Comment 10 Telesto 2019-12-19 19:22:52 UTC
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
Comment 11 Buovjaga 2019-12-19 19:34:24 UTC
Xisco, Telesto: can you shed light on why you disagree with the status?
Comment 12 Telesto 2019-12-19 19:49:25 UTC
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."
Comment 13 Buovjaga 2019-12-19 20:05:33 UTC
(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?
Comment 14 Telesto 2019-12-19 22:44:31 UTC
(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
Comment 15 Xisco Faulí 2019-12-19 23:23:11 UTC
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 ?
Comment 16 Julien Nabet 2019-12-20 22:44:47 UTC
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.
Comment 17 Julien Nabet 2019-12-20 22:50:05 UTC
Created attachment 156710 [details]
perf flamegraph (first print opening dialog)

Here's the Flamegraph when opening print dialog first time
Comment 18 Xisco Faulí 2020-01-21 12:42:33 UTC
Putting it to NEW