Bug 118822 - PDF export with bitmap Page background rather slow (not with lossless)
Summary: PDF export with bitmap Page background rather slow (not with lossless)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, perf
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2018-07-18 13:52 UTC by Telesto
Modified: 2019-04-26 13:57 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (145.12 KB, application/vnd.oasis.opendocument.text)
2018-07-18 13:52 UTC, Telesto
Details
perf flamegraph (3.83 MB, image/svg+xml)
2019-04-22 14:12 UTC, Julien Nabet
Details
Perf flamegraph (412.87 KB, image/svg+xml)
2019-04-25 18:20 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-07-18 13:52:17 UTC
Description:
PDF export with bitmap Page background rather slow

Steps to Reproduce:
1. Open the attached file
2. Export to PDF default settings

Actual Results:
Slow on Windows, certainly compared with Linux

Expected Results:
Same speed as Linux. Say 5 seconds not 30 seconds


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.2.0.0.alpha0+
Build ID: e7d3976cb80f7e7401be071f905a764dd6cb4d6e
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-29_04:46:32
Locale: nl-NL (nl_NL); Calc: CL

and in
3.3.0
Comment 1 Telesto 2018-07-18 13:52:36 UTC
Created attachment 143617 [details]
Example file
Comment 2 MM 2018-07-22 20:24:56 UTC
I see that on windows and linux it exports very fast with lossless, but not with jpg 90% (on both systems).

So confirmed on windows 7 x64 with Version: 6.0.6.1 (x64)
Build ID: dc68ad6c5cde3c62874b96422f2e5e8252499bad
CPU threads: 3; OS: Windows 6.1; UI render: default

and on ubuntu 16.04 x64 with Version: 6.2.0.0.alpha0+
Build ID: bab37647c4366c4f422d577a65cb8d91cb49ded2
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-07-20_21:38:04
Locale: en-US (en_US.UTF-8); Calc: threaded
Comment 3 Buovjaga 2018-09-01 13:10:13 UTC
Adding wantBacktrace: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_callgrind_trace
I am unable to do it because callgrind dumps for me on startup these days.
Comment 4 Julien Nabet 2019-04-22 11:37:30 UTC
buovjaga: thought you might be interested in this one.
Would it be possible you give a step by step procedure to retrieve a flamegraph?
Comment 5 Telesto 2019-04-22 11:47:59 UTC
(In reply to Julien Nabet from comment #4)
> buovjaga: thought you might be interested in this one.
> Would it be possible you give a step by step procedure to retrieve a
> flamegraph?

I asked the same (e-mail). Quote from Buovjaga:
I started doing them after asking Noel, if he finds my callgrind traces for fileopen bugs useful. He said he always does the traces again using perf. I had forgotten that Noel wrote instructions about perf + flamegraph: https://wiki.documentfoundation.org/Development/How_to_debug#Performance_debugging_.28perf.29

I decided to start doing the traces with perf primarily, because callgrind can take a hell of a long time. As mentioned in the wiki section, perf "produces less detailed output than callgrind, but is much cheaper to run (since it's a sampling profiler)". If the perf result is not enough, we (or a dev wanting to fix something) could always use callgrind.

Noel advised me to use a sampling frequency of 200.

So if I am recording something that is not fileopen, I give the command:
perf record -F 200 --call-graph dwarf --pid=`pidof soffice.bin`

and then hit Ctrl-C in the terminal after the action in LibreOffice was completed.

Then I do this in the same dir with the perf.data to create the flamegraph (the scripts are in my path, installed flamegraph-git from Arch Linux AUR repo):
perf script | stackcollapse-perf | flamegraph --width 4096 --height 24 > perf.svg

If I want to do a fileopen trace:
export OOO_EXIT_POST_STARTUP=1; perf record -F 200 --call-graph dwarf ~/libreoffice/instdir/program/soffice document.odt
Comment 6 Buovjaga 2019-04-22 12:18:57 UTC
Yep, I have these aliases in my .bashrc:
alias perfexit='export OOO_EXIT_POST_STARTUP=1; perf record -F 200 --call-graph dwarf ~/libreoffice/instdir/program/soffice'
alias perflibo='perf record -F 200 --call-graph dwarf --pid=`pidof soffice.bin`'
alias perfsvg='perf script | stackcollapse-perf | flamegraph --width 4096 --height 24 > perf.svg'

Julien: would you like to try it? :)
Comment 7 Julien Nabet 2019-04-22 12:56:30 UTC
(In reply to Buovjaga from comment #6)
> Yep, I have these aliases in my .bashrc:
> alias perfexit='export OOO_EXIT_POST_STARTUP=1; perf record -F 200
> --call-graph dwarf ~/libreoffice/instdir/program/soffice'
> alias perflibo='perf record -F 200 --call-graph dwarf --pid=`pidof
> soffice.bin`'
> alias perfsvg='perf script | stackcollapse-perf | flamegraph --width 4096
> --height 24 > perf.svg'
> 
> Julien: would you like to try it? :)

Yes quite interested! :-)
I changed the perfexit alias so it corresponds to my env but then what should I do?
I mean, I suppose I must download first scripts about flamegraph and install them somewhere?
Then, what alias to launch?
Comment 8 Buovjaga 2019-04-22 13:21:55 UTC
(In reply to Julien Nabet from comment #7)
> Yes quite interested! :-)
> I changed the perfexit alias so it corresponds to my env but then what
> should I do?
> I mean, I suppose I must download first scripts about flamegraph and install
> them somewhere?
> Then, what alias to launch?

For this report, you should use perflibo type of command, where you first launch LibO, open the PDF export dialog and then give perflibo in a terminal. Then after the exporting is done, hit Ctrl-C in the terminal where perf is running.

Steps:
1. Install perf from your distro's package repo
2. git clone https://github.com/brendangregg/FlameGraph
3. Do the perf trace like I described above. A file called perf.data is created
4. Do the SVG graphing so you point to the .pl scripts. A file called perf.svg is created.

In the How to debug section we have:
perf script | ../FlameGraph/stackcollapse-perf.pl | ../FlameGraph/flamegraph.pl --width 4096 --height 24 > perf.svg
   firefox perf.svg

So just replace the paths to where you cloned FlameGraph
Comment 9 Julien Nabet 2019-04-22 14:12:35 UTC
Created attachment 150918 [details]
perf flamegraph

Thank you Buovjaga! :-)
Comment 10 Buovjaga 2019-04-25 17:59:38 UTC
(In reply to Julien Nabet from comment #9)
> Created attachment 150918 [details]
> perf flamegraph

In another report, it was pointed out you used a debug build instead of one with --enable-symbols. I added a note about this in the wiki.

When you switch from debug build to a symbols build, you have to do a make clean first.
Comment 11 Julien Nabet 2019-04-25 18:09:00 UTC
(In reply to Buovjaga from comment #10)
> (In reply to Julien Nabet from comment #9)
> > Created attachment 150918 [details]
> > perf flamegraph
> 
> In another report, it was pointed out you used a debug build instead of one
> with --enable-symbols. I added a note about this in the wiki.
> 
> When you switch from debug build to a symbols build, you have to do a make
> clean first.

Thank you for the piece of advice!
Since I always use enable-dbgutil to have full debug, I'll avoid doing flamegraph then.
Comment 12 Buovjaga 2019-04-25 18:20:11 UTC
Created attachment 151012 [details]
Perf flamegraph

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: a0edb53e63b9fa7ed5983d6500aece1e5eff380b
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 25 April 2019
Comment 13 Buovjaga 2019-04-26 10:49:44 UTC
(In reply to Julien Nabet from comment #11)
> Thank you for the piece of advice!
> Since I always use enable-dbgutil to have full debug, I'll avoid doing
> flamegraph then.

For what it's worth, Noel is using this method for many workdirs: https://wiki.documentfoundation.org/Development/BuildingOnLinux#Multiple_Work_Dirs
Most of his workdirs are debug, one is release for doing perf work.
Comment 14 Julien Nabet 2019-04-26 12:50:05 UTC
(In reply to Buovjaga from comment #13)
> (In reply to Julien Nabet from comment #11)
> > Thank you for the piece of advice!
> > Since I always use enable-dbgutil to have full debug, I'll avoid doing
> > flamegraph then.
> 
> For what it's worth, Noel is using this method for many workdirs:
> https://wiki.documentfoundation.org/Development/
> BuildingOnLinux#Multiple_Work_Dirs
> Most of his workdirs are debug, one is release for doing perf work.

If I well understand, if it's just a ref, no need to use git pull -r on both workdirs, just 1 of them?
If yes, I can use "git pull -r" on initial workdir or ref workdir, or only on initial workdir?
Comment 15 Buovjaga 2019-04-26 13:57:00 UTC
(In reply to Julien Nabet from comment #14)
> If I well understand, if it's just a ref, no need to use git pull -r on both
> workdirs, just 1 of them?
> If yes, I can use "git pull -r" on initial workdir or ref workdir, or only
> on initial workdir?

I asked Noel and he replied: "the different workdirs act independently, just that the first one is like a primary cache for git data"