Perl会成为这种图像处理的瓶颈吗？

Question

我想到的处理是：

• 有数以千计的png文件
• 应加载每个，并访问其像素
• 每个像素的通道将以某种方式处理，然后写入二进制文件

我正在考虑使用某种模块，比如ImageMagick包装器，或者其他一些用于C图像处理后端的包装器。如果我选择执行此任务，Perl会减慢我的速度吗？我有一个用Java编写的工具（它使用JDK的BufferedImage），它的速度相当快。我会因为期待Perl的速度而感到疯狂吗？

Answer 1

如果您正在使用ImageMagick或其他任何其他基于C的处理工具，perl肯定不会成为瓶颈。我能看到的瓶颈（特别是如果处理数千个文件）将是：

• 磁盘IO速度
• 内存访问速度
• 库算法速度

Perl将为您的需求做出巨大贡献。缓慢的部分仍然会很慢。您也可以轻松制作快速部件。 ：）

另外，请记住两个优化规则：

1. 不要这样做。
2. （仅限专家：）不要这样做。

当你把它放在一起时，在它上面运行一个分析器。如果成为您的目标，请查看：

http://metacpan.org/pod/Devel::NYTProf

Devel :: NYTProf在分析工具方面几乎是蜜蜂的膝盖。它会告诉你减速的确切位置，所以你不仅要有一种“温暖模糊”的感觉，你说得对......你肯定会知道的。

Answer 2

我不这么认为，除非您的Perl代码在紧密循环中过度依赖方法调用。 但如果实际的图像处理是在C后端完成的，那么Perl在性能方面不会成为瓶颈。

Answer 3

答案取决于Java版本中限制性能的因素。如果你受文件I / O（包括.png解压缩）的限制，那么转移到Perl可能会没问题。否则，你可能会为处理Perl中的每个像素而付出陡峭的性能损失，但如果你可以调用C例程来处理整个图像，那么你可能会同样快（可能更快，取决于相对性能） C和Java库。）

所以，简而言之：如果Perl必须触摸像素，它将会很慢。如果Perl触摸图像而C接触像素，则可能没问题。

Answer 4

是的，我希望perl实现的性能在像素级图像处理方面会非常糟糕。

是的，你可以做到，但Perl的数据结构不适合这种事情。如果您使用的是不需要为每个像素拨打1x电话的库，那么你会没事的。