Well I didn't check why it happens, but running bug689189.pdf with pdfwrite appears much slower that a rasterization with -r300 ppmraw. I'd appreciate if ken checks it because it slows down my local regression tool.
For me, on Windows, with: gswin32c -dNOPAUSE -sDEVICE=pdfwrite -dBATCH -sOutputFile=a.pdf anniversaire.pdf and gswin32c -dNOPAUSE -sDEVICE=ppmraw -r300 -dBATCH -sOutputFile=a.raw anniversaire.pdf Both jobs take ~15 seconds. My source is a little out of date, I will resynch to the repository later and try again. Unless I did something wrong with the command parameters ?
Updated to HEAD, and tried again, same parameters. This time it takes 21 seconds for ppmraw and 14 seconds for PDFwrite. I must be doing something wrong, can you tell me your command line please ?
Leo, did you ever get a chance to try this again ? I'm unable to see any reduction in performance compared with ppmraw. If you have a command line invocation I can try I'll give it another go, otherwise I'd like to close this, as I don't see a problem.
Well, now it slower as about 4/3. But I observe another problem : our pdfwrite generates 5965621 bytes when the source PDF is 2168317 bytes. As I know the document renders same shading thousands times, and I'm not sure that pdfwrite correctly recognize them as instances of same shading. So here we still have a room for improvement, but maybe the bug title isn't perfect. Note I run comparefiles/bug689189.pdf rather than anniversaire.pdf, which is attached to several bugs in different versions. Please check for sure whether they're identical.
The copy of anniversaire.pdf I was using is identical to the one in (my copy of) comparefiles/bug689189.pdf. As regards timing, using a copy of HEAD and the two command lines I mentioned before, I see ppmraw taking 12 seconds, and pdfwrite taking 14 (averages over 5 runs each). I guess that's fairly close to what you see, but it doesn't seem excessive ? I did notice the increase in size, assuming this is due to redundant shadings we already have an issue open against that, #689247. I would guess that reducing the number of shadings, and therefore the file size written would make the time broadly comparable to the ppm raw result. So, since we already have an open issue to track the shadings, which uses the same test file (apparently there are 8000+ shadings), I'd like to close this one if you don't mind,a dnd continue to track the duplicate shadings in #689247.
Ok, close this one as dup.
Thanks, done. One day I may even get to the duplicate shadings problem ;-) *** This bug has been marked as a duplicate of 689247 ***