Image Magick slow

ImageMagickObject is a Windows COM+ interface to ImageMagick. COM+, Visual Basic, and Delphi users should post to this discussion group.
Post Reply
Posts: 1
Joined: 2014-06-02T06:00:48-07:00
Authentication code: 6789

Image Magick slow

Post by BTPond »

Hello everyone,
I'm running ImageMagick 6.8.6-8 on two different Windows servers both with multi-processors. Same code, same images, one server finishes in about 2 seconds the other takes over a minute. I switched the slow one to a Q8 version of IM 6.8.1-10 and it's still taking a good 40+ seconds. Having read the boards I've heard there is/was a problem with OpenMP that can cause massive slow-down (though as I said both servers are multi-processor so why one should be slow and not both is a little odd). I've tried setting the threads policy to "1", didn't see any noticeable change in behavior. Again, consensus says building from source and disabling OpenMP is the ultimate solution. Can this be done if I'm using ImageMagickObject? Is there a documented "stable" version of IM that does not have the OpenMP slow-down bug? I've checked virus scan to make sure that's not affecting anything, any other ideas about what might cause the slowdown? Below is the function calls I'm using in case that helps any. It should be fairly straight forward though I am resizing and composing in the same command, do these need to be broken up or otherwise changed to speed things up? Just creating the blank canvas takes nearly a full second, the composites are taking between 6 and 12 seconds each. A.png is 230Kb 315X700, B.png is 34.1Kb 192X87, output.png results in 2365Kb 3150X3500.
Any help is greatly appreciated.

Posts: 49
Joined: 2012-10-12T16:50:15-07:00
Authentication code: 67789

Re: Image Magick slow

Post by Alexvb6 »


Are you using the 32-bit or 64-bit version of IM ?

I have experienced very long (sometimes infinite) time taken when using canvas as big as yours (3150X3500) when using a 32-bit version of IM.
On the 32-bit version under Windows, only 3Gb are available, as you can see it : identify -list resource

The 64-bit version is able to use all the available RAM (provided you did not reduced it in the "policy.xml" file (which is located in the folder IM is installed on).

Switching to IM x64 solved my problem in some cases.

However, when using '-draw' over large canvas with IM x64 v 6.9.9, it would crash with "too many primitives / bezier curves"
IM v7 **SHOULD** have this issue solved, but as far as 7.0.7-28, there is still a flaw, that should be fixed soon in a later release, as specified in this post : ... 07#p155007 (see the message by magick » 2018-03-30T07:15:05-07:00)
Post Reply