Description: Poor performance sending a printjob on Windows Steps to Reproduce: 1. Open attachment 160498 [details] 2. Print -> PRINT to a PDF -> wait 3 minutes Actual Results: 3 minutes Expected Results: 30-40 seconds Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 191288d6a7fb52b31038a21c4e71ee57ffa3bacd CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and in 3.3.0
Not a duplicate of bug 116399.. this is slow all the way back to 3.3.0
For me: Microsoft PDF: 5m30s Pdf creator: 2m55s Export to pdf: 15s Version: 6.4.4.2 (x64) Compilation: 3d775be2011f3886db32dfd395a6a6d1ca2630ff Subprocs. CPU: 4; SO: Windows 10.0 Build 19608; Repres. IU: GL; VCL: win; Configuration regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded
I forgot.. exporting to PDF and sending print job from PDF reader to PDF printer: 30 seconds
*** Bug 116399 has been marked as a duplicate of this bug. ***
Created attachment 162801 [details] BT with symbols VTune Profiler based on x39 build
Created attachment 162802 [details] BT with symbols VTune Profiler based on x39 build part2
Created attachment 162803 [details] BT with symbols VTune Profiler based on x39 build
Let's note: as essential feature for an text editor/spreadsheet/presentation tool That people also use to printer large documents. Especially in large organisations That it can take up to 5 times longer compared to printing the same file from PDF That Windows being used a lot -> Increasing priority.. It should be possible doing this faster, based on the PDFexport. Can we not generate some sort of PDF file and send that to the printer. For the record.. traces are only sample where time is spend.. It's on a 30/30/30 basis.
@Noel Not sure if you'r able to do the perf magic also outside the Linux environment. I hope so :-) Printing - sending the printjob - on Windows is simply slow.
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
Around 4 minutes in Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: bff60eadeac348024849d710690435ee9580831b CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded