Ghostscript (PS->PDF) Terrible Performance Under 11.1 Compared To 10.3

[Adam Tauno Williams]

We use openSUSE for our Intranet web servers, which frequently convert
documents to PDF using a2ps/ps2pdf. Under openSUSE 10.3 (GS 8.15.4-3.2)
this process is very fast. Unfortunately after upgrading to openSUSE
11.1 (GS 8.62-31.43.1) we find the process to be excruciatingly slow.
With just a 135KB PDF, containing no images, we see times like:

openSUSE 10.3: real 0m1.5s user 0m0.4s sys 0m1.1s
openSUSE 11.1: real 0m5.2s user 0m1.6s sys 0m3.6s

so that is quite a bit slower proportionally. But run a 632 page
postscript file (again, no images) and...

openSUSE 10.3: real 0m4.680s user 0m3.912s sys 0m0.768s
openSUSE 11.1: effectively never finishes

This is the time for running the following command:
/usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=file.pdf -dSAFER -c .setpdfwrite -f file.ps

openSUSE 10.3:
ghostscript-fonts-std-8.15.4-3.2
ghostscript-library-8.15.4-3.2
openSUSE 11.1
ghostscript-library-8.62-31.43.1.i586
ghostscript-fonts-std-8.62-31.43.1.i586
ghostscript-x11-8.62-31.43.1.i586
ghostscript-fonts-other-8.62-31.43.1.i586
ghostscript-omni-8.62-31.43.1.i586

I've tried removing ghostscript-omni to no effect. I've watched with
"strace -c" and it doesn't appear to be spending all it's time in system
calls, so it is Ghostscript itself. During the run time the gs process
pegs the CPU.

Any suggestions would be very appreciated.

-----
OpenGroupware developer: ***@whitemice.org
<http://whitemiceconsulting.blogspot.com/>
OpenGroupare & Cyrus IMAPd documenation @
<http://docs.opengroupware.org/Members/whitemice/wmogag/file_view>

[Dr. Werner Fink]

Post by Adam Tauno Williams
We use openSUSE for our Intranet web servers, which frequently convert
documents to PDF using a2ps/ps2pdf. Under openSUSE 10.3 (GS 8.15.4-3.2)
this process is very fast. Unfortunately after upgrading to openSUSE
11.1 (GS 8.62-31.43.1) we find the process to be excruciatingly slow.
openSUSE 10.3: real 0m1.5s user 0m0.4s sys 0m1.1s
openSUSE 11.1: real 0m5.2s user 0m1.6s sys 0m3.6s
so that is quite a bit slower proportionally. But run a 632 page
postscript file (again, no images) and...
openSUSE 10.3: real 0m4.680s user 0m3.912s sys 0m0.768s
openSUSE 11.1: effectively never finishes
/usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=file.pdf -dSAFER -c .setpdfwrite -f file.ps
ghostscript-fonts-std-8.15.4-3.2
ghostscript-library-8.15.4-3.2
openSUSE 11.1
ghostscript-library-8.62-31.43.1.i586
ghostscript-fonts-std-8.62-31.43.1.i586
ghostscript-x11-8.62-31.43.1.i586
ghostscript-fonts-other-8.62-31.43.1.i586
ghostscript-omni-8.62-31.43.1.i586
I've tried removing ghostscript-omni to no effect. I've watched with
"strace -c" and it doesn't appear to be spending all it's time in system
calls, so it is Ghostscript itself. During the run time the gs process
pegs the CPU.
Any suggestions would be very appreciated.

The version 8.62 has an completly rewritten pdfwrite API which is much
more compatible with the PDF standard. Beside this it can handle much
more PostScript code fid out there. This cause the longer compilation
time. This has nothing todo with omni o r any other device interface,
it is simply the device pdfwrite its self.

Beside this check if you're uptodate with ghostscript as there was
some fixes not only security fixes. Last changelog entry is

Wed May 13 17:26:49 CEST 2009 - ***@suse.de
- Complete patch for CVE-2009-0792 (bnc#491897)


if this version hangs on your file you may use

strace -p `pidof gs`

to see what happens here.


Werner

[Randall R Schulz]

Post by Dr. Werner Fink
...
The version 8.62 has an completly rewritten pdfwrite API which is
much more compatible with the PDF standard. Beside this it can
handle much more PostScript code fid out there. ...

That is good to know and, I hope, good news. In the past I have
all-too-often encountered PostScript files that produced poorly encoded
PDF files. These PDF files could be viewed and printed but not copied
from or searched (copying yielded gibberish; I suppose there was some
gibberish you could enter in order to search, but there was no way to
know what that was). I hope that's now a thing of the past.

Post by Dr. Werner Fink
Werner

Randall Schulz

[Adam Tauno Williams]

Post by Dr. Werner Fink

Post by Adam Tauno Williams
We use openSUSE for our Intranet web servers, which frequently convert
documents to PDF using a2ps/ps2pdf. Under openSUSE 10.3 (GS 8.15.4-3.2)
this process is very fast. Unfortunately after upgrading to openSUSE
11.1 (GS 8.62-31.43.1) we find the process to be excruciatingly slow.
openSUSE 10.3: real 0m1.5s user 0m0.4s sys 0m1.1s
openSUSE 11.1: real 0m5.2s user 0m1.6s sys 0m3.6s
sothat is quite a bit slower proportionally. But run a 632 page
postscript file (again, no images) and...
openSUSE 10.3: real 0m4.680s user 0m3.912s sys 0m0.768s
openSUSE 11.1: effectively never finishes
/usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=file.pdf -dSAFER -c .setpdfwrite -f file.ps
I've tried removing ghostscript-omni to no effect. I've watched with
"strace -c" and it doesn't appear to be spending all it's time in system
calls, so it is Ghostscript itself. During the run time the gs process
pegs the CPU.
Any suggestions would be very appreciated.

The version 8.62 has an completly rewritten pdfwrite API which is much
more compatible with the PDF standard. Beside this it can handle much
more PostScript code fid out there. This cause the longer compilation
time.

A 400% increase for a small (135KB) file and from 4 seconds to hours for
a 3MB file?

Post by Dr. Werner Fink
This has nothing todo with omni o r any other device interface,
it is simply the device pdfwrite its self.
Beside this check if you're uptodate with ghostscript as there was
some fixes not only security fixes. Last changelog entry is
- Complete patch for CVE-2009-0792 (bnc#491897)

I'm up to date as far as the openSUSE repository is concerned. Should I
try to pull the ghostscript package from Factory?

Post by Dr. Werner Fink
if this version hangs on your file you may use
strace -p `pidof gs`
to see what happens here.

Just a constant stream of -
...
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
\5P\300@"..., 60) = 60
brk(0xf959000) = 0xf959000
brk(0xf949000) = 0xf949000
brk(0xf948000) = 0xf948000
brk(0xf96f000) = 0xf96f000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
\5P\300@"..., 60) = 60
brk(0xf95f000) = 0xf95f000
brk(0xf94f000) = 0xf94f000
brk(0xf94e000) = 0xf94e000
brk(0xf975000) = 0xf975000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
\5P\300@"..., 60) = 60
brk(0xf965000) = 0xf965000
brk(0xf955000) = 0xf955000
brk(0xf954000) = 0xf954000
brk(0xf975000) = 0xf975000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
\5P\300@"..., 60) = 60
...

[Dr. Werner Fink]

Post by Adam Tauno Williams

Post by Dr. Werner Fink
The version 8.62 has an completly rewritten pdfwrite API which is much
more compatible with the PDF standard. Beside this it can handle much
more PostScript code fid out there. This cause the longer compilation
time.

A 400% increase for a small (135KB) file and from 4 seconds to hours for
a 3MB file?

I'm only the maintainer of ghostscript *not* one of the developers nor
authors.

Post by Adam Tauno Williams

Post by Dr. Werner Fink
This has nothing todo with omni o r any other device interface,
it is simply the device pdfwrite its self.
Beside this check if you're uptodate with ghostscript as there was
some fixes not only security fixes. Last changelog entry is
- Complete patch for CVE-2009-0792 (bnc#491897)

I'm up to date as far as the openSUSE repository is concerned. Should I
try to pull the ghostscript package from Factory?

this will make no difference IMHO

Post by Adam Tauno Williams

Post by Dr. Werner Fink
if this version hangs on your file you may use
strace -p `pidof gs`
to see what happens here.

Just a constant stream of -
...
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
brk(0xf959000) = 0xf959000
brk(0xf949000) = 0xf949000
brk(0xf948000) = 0xf948000
brk(0xf96f000) = 0xf96f000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
brk(0xf95f000) = 0xf95f000
brk(0xf94f000) = 0xf94f000
brk(0xf94e000) = 0xf94e000
brk(0xf975000) = 0xf975000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
brk(0xf965000) = 0xf965000
brk(0xf955000) = 0xf955000
brk(0xf954000) = 0xf954000
brk(0xf975000) = 0xf975000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
...

looks like gs is writing out the resulting pdf and this seems
to take some time ... btw: how fast is your disk. Try out
to use /dev/null as OutputFile, does this go faster?

You may also replace

-c .setpdfwrite

with

-dCompressFonts=true -dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold'

if you have enough memory available in your system. You may have a look
into

w3m -T text/html -dump /usr/share/ghostscript/8.62/doc/Ps2pdf.htm | less -S
w3m -T text/html -dump /usr/share/ghostscript/8.62/doc/Use.htm | less -S '+/^Improving performance'



Werner

[Adam Tauno Williams]

Post by Dr. Werner Fink

Post by Adam Tauno Williams

Post by Dr. Werner Fink
The version 8.62 has an completly rewritten pdfwrite API which is much
more compatible with the PDF standard. Beside this it can handle much
more PostScript code fid out there. This cause the longer compilation
time.

A 400% increase for a small (135KB) file and from 4 seconds to hours for
a 3MB file?

I'm only the maintainer of ghostscript *not* one of the developers nor
authors.

Post by Adam Tauno Williams

Post by Dr. Werner Fink
if this version hangs on your file you may use
strace -p `pidof gs`
to see what happens here.

Just a constant stream of -
...
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
brk(0xf959000) = 0xf959000
brk(0xf949000) = 0xf949000
brk(0xf948000) = 0xf948000
brk(0xf96f000) = 0xf96f000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
brk(0xf95f000) = 0xf95f000
brk(0xf94f000) = 0xf94f000
brk(0xf94e000) = 0xf94e000
brk(0xf975000) = 0xf975000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
brk(0xf965000) = 0xf965000
brk(0xf955000) = 0xf955000
brk(0xf954000) = 0xf954000
brk(0xf975000) = 0xf975000
write(6, "x\234330P0PH1\340*\3442\4\261\f\24\240Tr\256\202S\10\227~\220
...

looks like gs is writing out the resulting pdf and this seems
to take some time ... btw: how fast is your disk.

Both machines (10.3 vs 11.1) are identical; they are virtual machines
on ESX servers connected to an EMC SAN.

Post by Dr. Werner Fink
Try out to use /dev/null as OutputFile, does this go faster?
You may also replace
-c .setpdfwrite
with
-dCompressFonts=true -dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold'
if you have enough memory available in your system.

Will test.

[Adam Tauno Williams]

Post by Adam Tauno Williams

Post by Dr. Werner Fink
looks like gs is writing out the resulting pdf and this seems
to take some time ... btw: how fast is your disk.

Both machines (10.3 vs 11.1) are identical; they are virtual machines
on ESX servers connected to an EMC SAN.

Post by Dr. Werner Fink
Try out to use /dev/null as OutputFile, does this go faster?
You may also replace
-c .setpdfwrite
with
-dCompressFonts=true -dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold'
if you have enough memory available in your system.

Will test.

I let -
time /usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=file.pdf -dSAFER -dCompressFonts=true
-dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold' -f
file.ps
- run for 233 minutes, then I started (to /dev/null) -
time /usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=/dev/null -dSAFER -dCompressFonts=true
-dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold' -f
file.ps
- and let that run for 102 minutes. Neither finished.

This just seems insane.

[Dr. Werner Fink]

Post by Adam Tauno Williams

Post by Adam Tauno Williams

Post by Dr. Werner Fink
looks like gs is writing out the resulting pdf and this seems
to take some time ... btw: how fast is your disk.

Both machines (10.3 vs 11.1) are identical; they are virtual machines
on ESX servers connected to an EMC SAN.

Post by Dr. Werner Fink
Try out to use /dev/null as OutputFile, does this go faster?
You may also replace
-c .setpdfwrite
with
-dCompressFonts=true -dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold'
if you have enough memory available in your system.

Will test.

I let -
time /usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=file.pdf -dSAFER -dCompressFonts=true
-dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold' -f
file.ps
- run for 233 minutes, then I started (to /dev/null) -
time /usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=/dev/null -dSAFER -dCompressFonts=true
-dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold' -f
file.ps
- and let that run for 102 minutes. Neither finished.

Do you have the PostScript file? Please attach this compressed and
send it in a PM to me.

Werner

[Adam Tauno Williams]

Post by Dr. Werner Fink

Post by Adam Tauno Williams
I let -
time /usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=file.pdf -dSAFER -dCompressFonts=true
-dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold' -f
file.ps
- run for 233 minutes, then I started (to /dev/null) -
time /usr/bin/gs -dSAFER -dCompatibilityLevel=1.2 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOutputFile=/dev/null -dSAFER -dCompressFonts=true
-dMaxInlineImageSize=0 -c '.setpdfwrite 300000000 setvmthreshold' -f
file.ps
- and let that run for 102 minutes. Neither finished.

Do you have the PostScript file? Please attach this compressed and
send it in a PM to me.

<https://bugzilla.novell.com/show_bug.cgi?id=509903>