|
|
1
11
我也遇到过这个问题——解决方案是强制垃圾收集。 当您将图像变量重新分配给新图像时,只需使用GC。开始确保从内存中释放旧引用。 在RMagick的后续版本中,我也相信你也可以称之为destroy!当您完成处理后,将显示在图像上。
或者,您可以使用 mini-magick 它是ImageMagick命令行客户端的包装器。 |
|
|
2
8
使用RMagick时,重要的是要记住在完成后销毁图像,否则在处理大型图像集时会填充/tmp dir。例如,您必须调用destroy!
|
|
|
3
5
实际上,这并不是Ruby特有的问题,其他解释器也有同样的问题。具体的问题是Ruby的GC只看到由Ruby本身分配的内存,而不是由外部库分配的内存(使用Rubys内存管理设施的库除外)。因此,Ruby内存空间中的ImageMagick对象非常小,但ImageMagick管理的空间中的图像很大。因此,这本身不是泄漏,但其行为类似于泄漏。 还有一个图书馆叫 MagickWand 作者蒂莫西·保罗·亨特(RMagick的作者),试图解决这些问题并创建更好的API。不过,它是alpha版本,需要一个新版本的ImageMagick。 |
|
|
4
1
我想
https://rmagick.github.io/constants.html
然而
|
|
|
5
-1
这不是由于ImageMagick;这是由于Ruby本身,这是一个众所周知的问题。我的建议是将程序分为两部分:一部分是分配很少内存的长时间运行部分,只处理系统的控制,另一部分是实际执行处理工作的单独程序。长时间运行的控制进程应该足以为它生成的子进程找到一些工作,子进程应该为该特定工作项完成所有处理。
另一种选择是将两者结合在一起,但在一个工作单元完成后,使用
这是假设工作项相当大,如果您使用ImageMagick,几乎可以肯定。如果没有,您会发现生成新进程和让Ruby解释器重新解析整个程序的开销开始变得有点太大。您可以通过让程序在重新执行之前执行更多的工作单元(例如,10或100)来解决这个问题。 |