Mikhail Teterin requested that I forward this tidbit of info to the list. The GraphicsMagick build currently distributed with FreeBSD 7.0 uses shared libraries but not loadable modules. Some testing I did today shows that FreeBSD is much slower at starting GraphicsMagick as a large static executable (with shared lib dependencies) than it is for a shared library, which itself much slower than the case where parts of the needed code are loaded using modules. This may imply that FreeBSD is abnormally slow at initializing large applications (e.g. Solaris 10 does not exhibit this anomaly since timings vary only by a few percent). For the timings below, I execute the command using this simple shell script: #!/bin/bash i=1 count=1000 time while test $i -lt $count do eval "$@" let i=i+1 done Here is the original email content sent to Mikhail Teterin: I performed some timings for executing a minimal GraphicsMagick command 'gm convert -size 1x1 'xc:#F00' null:' 1000 times. This is under FreeBSD. Static build: real 0m39.558s user 0m24.825s sys 0m14.853s Shared build: real 0m27.828s user 0m18.367s sys 0m9.728s Modules build: real 0m11.041s user 0m4.785s sys 0m6.737s I find it interesting that FreeBSD is not very efficient at starting large (mostly) static programs. Solaris is a lot better at this. Probably much of the difference in performance has to do with how the run-time linker works, and the amount of initialized data which needs to be set. With the static build I can push the generated image size to to 500x500 without much impact on the total run time. The execution overhead is that great. These differences may seem small but if gm is invoked from a simple shell script, it can make the difference between processing 25 small images per second or 90 images per second. Also, the consumed user and system time is dramatically less. Bob =====================================Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/