https://bugs.freedesktop.org/show_bug.cgi?id=51989
--- Comment #7 from Roman Eisele <b...@eikota.de> 2012-07-15 11:10:44 PDT --- Created attachment 64232 --> https://bugs.freedesktop.org/attachment.cgi?id=64232 Big book sample (3222 pp. .odt file in book typography, German, no images, graphics or tables, fonts included) Update: The decrease in PDF export performance does NOT (only) depend on images/graphics, it is measurable even with .odt files containing formatted text only, and it does depend exponentially on the .odt file size (count of pages, etc.): when you export a big .odt file to PDF, you will notice an even bigger decrease of performance. Test: To test with a real text sample (I am a bit distrustful about the value of tests with mere placeholder texts), I created a 3222 pp. .odt sample file in book typography -- no images, no graphics, no tables, only much German text, some nice formatting with a bit of color, using (semi-)professional fonts and styles. (If you wonder which text is free of copyright, but 3222 pp. long: it is the Bible in Luther's original 1545 German translation ;-) The .odt file is 1.9 MB in size. You find it together with the (free) fonts attached to this bug report. To test I just open the file, do nothing else, do not even scroll, just select "File > Export as PDF...", leave most settings at default, just select * General: "Export bookmarks" * General: "Export automatically inserted blank pages" * General: "Embed standard fonts" * Links: "Export bookmarks as named destinations" but don't select General: "Embed OpenDocument file", and click "Export". Results: I distinguish three stages of PDF export. In stage I, the progress bar is not yet visible, but the cursor turns to the spinning cursor or watch (depending on your OS, I suppose). In stage II, the progress bar is visible, but does not work yet, i.e. does not show any progress. In stage III, the pogress bar shows the progress of export. To distinguish these stages is important, because it may reveal something about where the decrease of performance occurs. All values are in seconds and the mean value of several tests with each version. LibO 3.4.6 LibO 3.5.53 LibO 3.6.0.1 ======================================================================== Export stage I 50 52 50 (spinning cursor) ------------------------------------------------------------------------ Exporr stage II 5 5 267 (!!!) (progress bar visible, but disabled) ------------------------------------------------------------------------ Export stage III 102 113 140 (progress bar showing progress) ======================================================================== Total 157 170 457 (!!!) You see, we have a little decrease of performance in LibO 3.5.x as compared to 3.4.x, but a big decrease in LibO 3.6.0.1 as compared to both older versions. The decrease happens partially in stage III of the export, but mostly in stage II. This stage, which took only 5 seconds in LibO 3.4.x and 3.5.x, and is, with small documents, so short that you may not even notice it, takes 267 seconds now in LibreOffice 3.6.0.1. Wow! I already thought that LibO 3.6.0.1 freezed, and this is really bad user experience. It seems that the duration of this stage depends exponentially on file size, even without any graphics. So the question is: WHAT does LibreOffice do in stage II? Here is the place of the biggest regression of performance against LibreOffice 3.5.x, and here our developers should look how to get performance back. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs