Printing speed is glacial for large file

users
#1

I have a project managed by an odm file that ends up being ca 1600 pages
long and contains several OLE objects, many graphics (some comprising
entire pages that started out as PDFs). I find LO unbelievably slow
(even on such simple things as refreshing the window after remapping
it). I've turned of recording/displaying changes, upped the graphics
cache numbers, set the swap directory to a ram disk, and turned off all
to-disk swapping; nothing helps. This is on a 2 CPU machine with gig's
of ram.

I'm currently trying to print the project to a file (postscript
format). This takes 4-6 hours, with 1 of the CPU's running at 100% [BTW
is LO multi-threaded?]. The resulting postscript file is big, (about
350M) but not that big.

I'm on a Slackware Linux box.

Any suggestions?

David

#2

I have a project managed by an odm file that ends up being ca 1600 pages
long and contains several OLE objects, many graphics (some comprising
entire pages that started out as PDFs). I find LO unbelievably slow
(even on such simple things as refreshing the window after remapping
it). I've turned of recording/displaying changes, upped the graphics
cache numbers, set the swap directory to a ram disk, and turned off all
to-disk swapping; nothing helps. This is on a 2 CPU machine with gig's
of ram.

I'm currently trying to print the project to a file (postscript
format). This takes 4-6 hours, with 1 of the CPU's running at 100% [BTW
is LO multi-threaded?]. The resulting postscript file is big, (about
350M) but not that big.

I'm on a Slackware Linux box.

Any suggestions?

David

Which version of LO are you using? That might help with some answers.

Have you made any modification the default settings of

Memory ?

I know that some people have seen some good results with the increasing of the different options for the memory usage for a document. Large ones that has a lot of object/graphics/images could use more cache memoryand a larger "number of objects". Then if you are not doing much editing, the reduction of the "Undo - number of steps" could free up some needed memory and response time for the document.

The 1600 pages long and many graphics can slow down any system, when you are "converting" the file to a postscript format.

By-the-way - what are you using for the print-to-postscriptprocess? I do not see that as a "included" part of LO 4.0.2. Are you printing it to a postscript printer but are saving it to a file instead of printing out to paper? That process would give our users some idea on the process and my have some of the try some things that might find some answers.

I use Ubuntu 12.04 with 2 HP printers [inkjet and laser], 1 Epson inkjet, and 1 Canon inkjet. None defaults to a postscript, but the HP laser has a postscript driver. I may install it and do some testing myself.

OK, I installed the foomatic-postscript driver for the laser printer. It can print to a file. But would I need it to usethe "generic postscript printer driver" to make it device independent as you seem to want it to be by "printing" the file to a postscript file?

#3

Hi :slight_smile:
I think swap doesn't get used much these days.  Can you try

free -m

before and during the process?  If swap is not being used even when it's in Ram then perhaps either stop using the ram-drive or increase swappiness?  I have 2Gb Ram but only about half that ever gets used and that's only when i really push the machine with games and video
Regards from
Tom :slight_smile:

#4

David,
There is a known problem with LO and Encapsulated PostScript (EPS) graphics. They slow down video rendering tremendously, causing frustrating long scrolling time. This may also cause a problem with printing, I never tried it. When I converted my document's EPS images to JPEG, LO rendering/scrolling sped up tremendously.
Hope this helps.
(Fellow Slacker.)
Girvin Herr

#5

Hi Girvin,

Most of the graphics in the document are PDF pages that I've imported
into Draw and then cut and pasted them into an odt file, which in turn
is incorporated into the full document as laid out in the odm file.

Also normal scrolling of the odm document is horrendously slow as well
(minutes to scroll to the next page and redraw).

David

#6

Hi :slight_smile:
I kinda assumed it was the extremely large file-size and number of pages?  I know people have written books with LO but isn't there something more fit-fot-purpose, such as inkscape?
Regards from
Tom :slight_smile:

#7

Have you attempted anything in particular to see if it allows for a speed improvement? For example:

1. Check on memory usage. How high is it? Are you running out of memory?

2. Change graphics settings:

Tools > Options > LibreOffice > Memory

Then try increasing the memory for things such as graphics objects and number of objects?

#8

Hi David,

Any suggestions?

I'm not certain, but it might have something do with the "Print to File"
being a synchronous code execution, so the app has to wait until the
data has been processed before being able to free up enough resources
for fluid redrawing of the screen.

In the old OOo developers guide, there is a mention about being able to
set printing to asynchronous programmatically, with the inherent
instability that such a setting might cause if the window containing the
app suddenly closes, but that might be one avenue of investigation.

There is also this general parameter setting mentioned here :

http://wiki.openoffice.org/wiki/Environment_Variables

Alex

#9

Hi Andrew,

Thanks for the reply. In short, I'd already upped the memory options
for graphics (250MB total, 10MB per object, 100 objects) and tools like
free etc. show that I'm nowhere close to using all my memory (with or
without swapping enabled).

David

#10

David,
That may or may not be true. I am not familiar with the "free", etc. tools you mention, but they may be reporting system free memory, while the LO settings are limits for LO and may be topping out while there is still free system memory available. I would take a look at the document file size and maybe triple that or more for the LO settings. Keep in mind that the file is compressed, so you should at least double that size, assuming a nominal 50% compression. You could count the number of graphics in your document to get the max number of graphics setting. 1600 pages is a lot. I have many "large" documents but I don't think any of them are 1600 pages. Maybe hundreds of pages at the most. So I don't have any experience with a document that large. Too bad LO doesn't have a memory pool usage dialog where one could see the memory usage. Hint, hint to the devs. With such a tool, we wouldn't need to be guessing about these settings. I suggest you try File -> Properties and select the "General" tab. There is a report on the document "Size" there. Use the "Statistics" tab to see some other allocations, such as number of graphics. Use of this data may help you zero in on acceptable memory allocation settings.
Hope this helps.
Girvin Herr

#11

I know that a professional writer of sci-fi and fantasy novels/paper-backs makes each chapter of his books a separate file, and he usually have 15 to 25 chapters.

I too have never heard of making a document more than 50 to 100 pages per file. Just paging through it would be slow, even on my mid-range quad desktop with 4 GB of RAM. To be honest, you might really find it better to break the document up by sections of no more than 50 pages or so, if possible. I know there must be a way to define the starting page number for each chapter, or do the sectional page numbering in the footer - i.e. Section VII Page 35

#12

Hi Kracked,

That's what I'm doing. I have 55 chapters in separate odt files and
use a master document (odm) to join them together, add a table of
contents and a cover page. While I can't call LO's speed on some of the
individual chapter files blindingly fast, especially on the lager ones
with lots of graphics, it's fast enough. The combined result is the
issue.

David

#13

Kracked_P_P---webmaster wrote:

To be honest, you might really find it better to break the document up by sections of no more than 50 pages or so, if possible.

Isn't that the purpose of master documents?

#14

Hi :slight_smile:
It might be worth asking the Documentation Team how they build-up their guides?
Regards from
Tom :slight_smile:

#15

Hi :slight_smile:
I am wondering if it's the 10Mb per object that is set too low?  If you are combining chapters are all chapters under 10Mb?  I would hope so but they might have excessively large graphics in them, such as un-scaled photos which can easily be 2-3Mb each without even trying.   Perhaps push that 10 up even higher? 
Regards from
Tom :slight_smile:

________________________________
From: Kracked_P_P---webmaster <webmaster@krackedpress.com>
To: users@global.libreoffice.org
Sent: Friday, 12 April 2013, 20:18
Subject: Re: [libreoffice-users] Printing speed is glacial for large file

I know that a professional writer of sci-fi and fantasy novels/paper-backs makes each chapter of his books a separate file, and he usually have 15 to 25 chapters.

I too have never heard of making a document more than 50 to 100 pages per file.  Just paging through it would be slow, even on my mid-range quad desktop with 4 GB of RAM.  To be honest, you might really find it better to break the document up by sections of no more than 50 pages or so, if possible.  I know there must be a way to define the starting page number for each chapter, or do the sectional page numbering in the footer - i.e. Section VII Page 35

David,
That may or may not be true.  I am not familiar with the "free", etc. tools you mention, but they may be reporting system free memory, while the LO settings are limits for LO and may be topping out while there is still free system memory available.  I would take a look at the document file size and maybe triple that or more for the LO settings.  Keep in mind that the file is compressed, so you should at least double that size, assuming a nominal 50% compression.  You could count the number of graphics in your document to get the max number of graphics setting.  1600 pages is a lot.  I have many "large" documents but I don't think any of them are 1600 pages.  Maybe hundreds of pages at the most. So I don't have any experience with a document that large.  Too bad LO doesn't have a memory pool usage dialog where one could see the memory usage.  Hint, hint to the devs.  With such a tool, we wouldn't need to be guessing about these settings.  I

suggest you try File -> Properties and select the "General" tab.  There is a report on the document "Size" there.  Use the "Statistics" tab to see some other allocations, such as number of graphics.  Use of this data may help you zero in on acceptable memory allocation settings.