Created attachment 143617 [details]
Example file

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

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.

buovjaga: thought you might be interested in this one.
Would it be possible you give a step by step procedure to retrieve a flamegraph?

(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

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? :)

(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?

(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

Created attachment 150918 [details]
perf flamegraph

Thank you Buovjaga! :-)

(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.

(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.

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

(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.

(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?

(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"

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://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug