Perl 会成为这种图像处理的瓶颈吗？
我想到的处理是这样的：
- 有数千个 png 文件，
- 每个文件都应该加载，并且访问
- 每个像素通道的像素将以某种方式进行处理，然后写入
我正在考虑使用某种排序的 二进制文件模块，如 ImageMagick 包装器，或用于 C 图像处理后端的其他包装器。如果我选择 Perl 来实现这个任务，它会减慢我的速度吗？我已经有一个用 Java 编写的工具（它使用 JDK 的 BufferedImage ），而且速度相当快。我会疯狂地期望 Perl 具有同样的速度吗？
The processing I have in mind is this:
- there are thousands of png files
- each of them should be loaded, and its pixels accessed
- each pixel's channels will be processed in some way, and then written to a binary file
I was thinking of using some sort of module, like ImageMagick wrappers, or some other wrapper for a C image processing backend. Will Perl slow me down if I choose it to implement this task? I have a tool already that's written in Java ( it uses JDK's BufferedImage ), and it's reasonably fast. Would I be crazy to expect the same speed from Perl?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您使用 ImageMagick 或其他任何其他基于 C 的处理工具，perl 肯定不会成为瓶颈。我可以看到的瓶颈（特别是在处理数千个文件时）是：
Perl 将成为您想做的事情的强大粘合剂。慢的部分仍然会很慢。你不妨让快速部分变得简单。 :)
另外，请记住两条优化规则：
当你把它放在一起时，对其运行分析器。如果这成为您的目标，请查看：
http://metacpan.org/pod/Devel： :NYTProf
Devel::NYTProf 在分析工具方面几乎是最出色的。它会准确地向您显示减速的位置，因此您不会只是有一种“温暖模糊”的感觉，认为自己做对了……您肯定会知道。
If you're using ImageMagick, or other any other C-based processing tool, perl will most certainly not be the bottleneck. The bottlenecks I could see (especially if processing thousands of files) would be:
Perl will make a great glue for doing what you want. The slow parts will still be slow. You might as well make the fast parts easy. :)
Also, remember the two Rules of Optimization:
When you do get it put together, run a profiler on it. If and when that becomes your goal, check out:
http://metacpan.org/pod/Devel::NYTProf
Devel::NYTProf is pretty much the bee's knees when it comes to profiling tools. It'll show you exactly where your slowdowns are, so you don't just have a "warm fuzzy" feeling that you have it right...you'll know for sure.
我不这么认为，除非您的 Perl 代码过度依赖紧密循环中的方法调用。
但如果实际的图像处理是在 C 后端完成的，Perl 将不会成为性能瓶颈。
I don't think so, unless your Perl code is over-reliant on method calls in a tight loop.
But if the actual image processing is done in C backend, Perl will not be a bottleneck performance-wise.
答案取决于 Java 版本中限制性能的因素。如果您受到文件 I/O（包括 .png 解压缩）的限制，那么迁移到 Perl 可能会没问题。否则，您可能会因为在 Perl 中处理每个像素而付出巨大的性能损失，但如果您可以调用 C 例程来处理整个图像，您可能会同样快（可能更快，具体取决于C 和 Java 库）。
所以，简而言之：如果 Perl 必须接触像素，它会很慢。如果 Perl 涉及图像而 C 涉及像素，则可能没问题。
The answer depends on what is limiting performance in the Java version. If you're limited by file I/O (including .png decompression), then moving to Perl will probably be fine. Otherwise, you're likely to pay a steep performance penalty for processing each pixel in Perl, but if you can call C routines to process entire images, you're likely to be just as fast (possibly faster, depending on the relative performance of the C and Java libraries).
So, in brief: if Perl must touch pixels, it will be slow. If Perl touches images and C touches pixels, it's probably fine.
是的，我预计 Perl 实现的性能在像素级图像处理方面会非常糟糕。
是的，你可以做到，但是 Perl 的数据结构不适合这种事情。如果您使用的库不需要每个像素进行 1 次调用，那就没问题了。
Yes, I expect the performance of a perl implementation would be incredibly sucky at pixel-level image manipulation.
Yes, you could do it, but Perl's data structures don't lend themselves to this kind of thing. If you were using a library where you don't need to make 1x call per pixel, you'll be fine though.