4

我想到的处理是这样的：

  • 有数千个 png 文件
  • 应该加载它们中的每一个，并访问其像素
  • 每个像素的通道都会经过某种处理，然后写入二进制文件

我正在考虑使用某种模块，例如 ImageMagick 包装器，或用于 C 图像处理后端的其他包装器。如果我选择 Perl 来实现这个任务，它会减慢我的速度吗？我已经有一个用 Java 编写的工具（它使用 JDK 的 BufferedImage ），而且速度相当快。如果期望 Perl 能达到同样的速度，我会发疯吗？

4

4 回答 4

9

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

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

Perl 将成为做你想做的事的好粘合剂。慢的部分仍然很慢。您不妨使快速部分变得容易。:)

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

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

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

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

在分析工具方面，Devel::NYTProf 几乎是蜜蜂的膝盖。它会准确地向您显示减速的位置，因此您不仅会有一种“温暖模糊”的感觉，那就是您做对了……您肯定会知道。

于 2010-02-13T22:58:56.980 回答
4

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

于 2010-02-13T21:19:14.730 回答
3

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

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

于 2010-02-13T22:49:26.920 回答
1

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

是的，你可以这样做，但是 Perl 的数据结构不适合这种事情。如果您使用的库不需要每像素进行 1 次调用，那么您会没事的。

于 2010-02-15T13:47:06.313 回答