Perl 语言的目标是在运行时生成快速的程序吗？
最近有朋友告诉我
“看 Perl 从来没有设计得很快”
- 这是真的吗？
我能找到的相关信息来自 维基百科：
该语言旨在实用（易于使用、高效、完整），而不是美观（微小、优雅、简约）。
但它并没有直接谈论速度。我认为，对于像 Perl 这样的语言来说，执行速度对于它需要完成的所有文本处理来说确实很重要。我同意，尽管有所有奇怪的语法，优雅从来都不是目标。
- 高速执行是 Perl 的设计目标之一吗？
I recently had a friend tell me
"see perl was never designed to be fast"
- Is that true?
The relevant piece of information I can find is this from Wikipedia:
The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal).
But it doesn't directly talk about speed. I think that with all the text processing that it needs to do, speed of execution really matters for a language like Perl. And with all the weird syntax, elegance was never an objective, I agree.
- Was high speed of execution one of the design objectives of Perl?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
有一个重要方面需要考虑：算法。 Perl 的秘密武器是支持某些语言功能和 CPAN 库的算法。
对于重要的问题，好的算法胜过原始的执行速度。在类 C 语言中选择和实现算法通常比在 Perl 中花费更多的精力。这意味着用半天时间编写一些小工具，perl 版本的性能通常优于 C 版本，因为使用散列以及使用语言和库中提供的功能更容易创建良好的数据结构。
There is one important aspect to be considered : algorithms. Perl secret weapons are the algorithms backing certain language features and the CPAN library.
Good algorithms trump raw execution speed for non trivial problems. It typically takes more effort to select and implement algorithms in C-like languages than in Perl. This means that for half a day coding some little tool the perl version often outperforms a C version because it was easier to make good datastructures with hashes and by using the features provided in the language and libraries.
一旦 Perl 脚本开始运行（即加载并编译所有内容之后），它的速度会非常快。每次都进行令人讨厌的编译，这有点令人讨厌。
然而，我发现人们实际上不必担心 Perl 的速度有多快。他们通过实施愚蠢的设计来浪费所有的时间，这些设计做了比他们需要做的更多的工作，误解了关键技术，或者只是愚蠢。对我来说，通过在正确的地方进行调整来帮助某人使他们的工作速度提高几个数量级的情况并不罕见。但这并不是 Perl 特有的。人们在使用每种语言时都会遇到这个问题。
Once a Perl script starts running (i.e. after loading and compiling everything), it can be very speedy. It's that yucky compile-every-time that's a bit nasty.
However, I find that people don't really have to worry about how fast Perl can be. They waste all of their time by implementing stupid designs that do a lot more work than they need to do, misunderstanding key technologies, or just being boneheaded. It's not uncommon for me to help someone make their stuff go orders of magnitude faster by just tuning in the right places. That's not particular to Perl though. People have that problem with every language.
Perl 始终以实用性为目标，而不是任何（甚至接近）某种象牙塔的纯粹性，其中一些目标被赋予绝对优先权，而其他目标则被忽略（完全或几乎如此）。
因此，我认为可以合理地说，保持合理的执行速度对于 Perl 来说一直被认为很重要，但是还有其他因素（特别是灵活性和易用性等因素）通常会影响 Perl 的性能。更重要的是，如果必须在其中一个因素和执行速度之间做出选择，那么另一个因素通常会获胜，除非对执行速度的影响非常严重。
Perl has always aimed toward practicality, not anything (even close to) some sort of ivory tower purity, where a few goals are given absolute priority, and others are ignored (completely or nearly so).
As such, I think it's reasonable to say that maintaining a reasonable speed of execution has always been seen as important for Perl, but there are other factors (especially things like flexibility and ease of use) that are generally more important, so if a choice has to be made between one of them and speed of execution, the other factor will generally win unless the effect on execution speed is really serious.
我想说的是，为最佳运行时性能而设计的语言不会具有允许在运行时进行编译的结构。所以也许不。
I would have said that a language that designed for optimal run time performance would not have constructs that allow compiling while running. So no, perhaps.
从 Perl 5.0 开始，它成为一个设计目标。但请记住，它仍然是解释性的，因此对于解释性语言来说它速度很快。
It became a design objective as of Perl 5.0. But keep in mind it is still interpreted, so it is fast for an interpreted language.