伙计们正在我的项目（java）中使用imagemagick库进行图像处理。当多个请求命中服务器时，响应速度非常慢。现在，多个convert命令（作为单个进程执行）同时执行，以避免在im4java中考虑process pooling的延迟。以下替代方案会有任何帮助吗？ ：
我应该选择 OTHER 方法吗？提前感谢您的帮助！
答案 0 :(得分：0)
实际上，我们的团队经历了完全相同的要求，因此我们创建了gm4java。它完全符合您的要求。至于对BufferedImage的支持，我们已经支持在latest release中使用BufferedImage作为输入。仍然不支持使用BufferedImage作为输出，但您可以轻松地解决它。
解决方法是让GM将映像写入RAM磁盘（在许多Linux发行版中，您可以免费获得RAM磁盘，对于Windows，可以使用各种解决方案）。您现在需要做的就是让您的Java代码从RAM磁盘读取转换后的图像。与每次启动新进程的巨大开销相比，开销很小（如果有的话）是无差别的。
即使直接将RAM磁盘方法与BufferedImage进行比较，BufferedImage的大小通常也比JPG图像文件的字节数组大10倍。因此，如果您只需要提供图像而不是在Java中进行额外处理，那么RAM磁盘方法确实更快，并且使用更少的内存。
有关im4java中当前BufferedImage实现的更多信息。当它用作输入时，它只是写入tmp文件，这非常慢。当使用它作为输出时，它使用stdin / stdout流操作，这比tmp文件更快但仍然不是最佳的。最好的方法是使用带有Java NIO实现的命名管道。但这需要相当多的，比如API破坏，im4java的变化。
最后，我不认为gm4java是im4java的包装器，gm4java的核心单独运行，并且让你能够向GM发送大量并发命令并将GM的输出返回给你。命令只是一个字符串列表，所以如果你知道如何编写GM命令，你不需要im4java来使用gm4java。这实际上就是我们在需要原始性能的应用程序中使用的方式。 im4java为您提供了一种方便的方法（有一些开销）来构建GM命令并解析GM输出。 gm4java中的GMBatchCommand类提供了im4java和gm4java之间的桥梁。它让你使用im4java的方便来构造命令，然后使用gm4java引擎来执行命令。 gm4java引擎使用与im4java完全不同的机制来管理和与GM通信。这就是为什么它如此之快的原因。