Legacy ImageMagick Discussions Archive

You can see from the logging above that ImageMagick took 25 minutes (8:28 - 8:53). I called Ghostscript directly for the same input by typing this: and the conversion took only 3 minutes by a memory usage peak of 90MB! This means ImageMagick spends 22 minutes by just throughputting, am I right?

P.S.: The -verbose output of ImageMagick says "gswin32c.exe" but I don't have this file on my computer. So parts of the -verbose message seems to be faked. Furthermore, the second -f parameter is strange since it isn't necessary on conversion.

It seems so. Perhaps its Windows because the same conversion takes less than 3 minutes on my Linux box.

magick wrote:It seems so. Perhaps its Windows because the same conversion takes less than 3 minutes on my Linux box.

File writing to disk cannot be the reason since Ghostscript uses it also if called directly.

The bottleneck may be your data piping to the called process. I don't know what the interface to GS is but I remember techniques of a localhost TCP socket sending, shared memory or data piping via Qt's class QProcess. I don't remember they are slow on Windows.

Data is available from disk, so there is no piping in this workflow. ImageMagick the same codeset under both Windows and Linux. ImageMagick saves the entire book on disk after its rendered before it is written as PNG to disk. Perhaps the I/O is slow under Windows. That's a big differential-- under 3 minutes under Linux and over 15 minutes under Windows.

magick wrote:Data is available from disk, so there is no piping in this workflow.

I understand this as if Ghostscript is commanded to load its input from and save its output to disk. Do you call Ghostscript as external process or as thread from a GS library within your program?

magick wrote:ImageMagick saves the entire book on disk after its rendered before it is written as PNG to disk.

This is a logically absolutely confusing sentence. I understood that you just call Ghostscript and command it to convert 1 PDF file to multiple PNG files. But now you write there are 3 steps:
1. rendering (by IM or GS?)
2. ImageMagick saves the entire book on disk (Why IM? I thought GS saves it, doesn't it?)
3. is written (by which IM or GS???) as PNG to disk (saved to disk again? Why twice?)

Perhaps the I/O is slow under Windows.

Saving 3MB never ever takes several minutes on Windows. Even a MS DOS PC 20 years ago saved faster. This is clearly a program issue.

The best explanation comes from http://www.imagemagick.org/script/architecture.php. Understanding the architecture explains why ImageMagick takes so long to process the book but not why its so fast on Linux than on Windows.

I can't get it why ImageMagick doesn't just call Ghostscript as external call doing the conversion. But maybe I take a look at your architecture description. I think I'm at a dead end here. Thanks for your replies anyway.

Hi,

We get also slow process with Windows (XP, Seven, ...). It's more 2x slower than on a Linux.
What can I do to improve speed on Windows ?

Hello,

I also had such a problem recently. In my case, Mac OS was able to process under 3 minutes and Windows 10 64Bit same process takes 1 hour.

I had x86 version of IM installed on a 64Bit OS. x86 version builds of IM seemingly does not have OpenMP included.

Slowness problem fixed when I switch my version of IM to 64bits which has OpenMP build in.

It might help to have one additional build just for x86 versions with OpenMP build in. I know more than several Windows computers running on multi-core CPU and 32Bit OS.

Thanks.

Let me describe my experience. As a computer vision engineer, I had to detect symbols on blueprints scanned as A3 600 dpi PDF files. That's 9k by 7k pixels! Linux and MacOS.

At first I used `convert` utility and it took ~40 seconds to convert a single page. We used this solution until we had to convert larger blueprints (20k by 14k), and it took ~2 minutes because it required 6.5 GB of memory (!!), so memory swapping occurred.

I read this discussion and thanks to you guys I started to use GhostScript backend directly. Now A3@600 dpi takes 2 seconds to convert and huge pdfs less than 5 seconds to convert with much lower RAM requirements.