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: 2021-04-26 03:47 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"
Comment 16 QA Administrators 2021-04-26 03:47:15 UTC
Dear Telesto,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug