Jör*_*tag 51
没有.
动态语言并不比静态语言慢.实际上,任何语言(动态或非动态)都不可能比另一种语言慢(或者更快,就此而言),因为语言只是一堆抽象的数学规则.你不能执行一堆抽象的数学规则,因此它们永远不会慢(呃)或快(呃).
"动态语言比静态语言慢"的说法不仅错误,甚至没有意义.如果英语是一种打字语言,那么这句话甚至都不会出现.
为了使语言能够运行,必须首先实现它.现在您可以测量性能,但是您没有测量语言的性能,而是测量执行引擎的性能.大多数语言都有许多不同的执行引擎,具有非常不同的性能特征 例如,对于C,最快和最慢实现之间的差异是100000左右!
此外,您无法真正衡量执行引擎的性能:您必须首先编写一些代码才能在该执行引擎上运行.但是现在您没有测量执行引擎的性能,您正在测量基准代码的性能.这与执行引擎的性能几乎没有关系,当然与语言的性能无关.
通常,在精心设计的高性能执行引擎上运行设计良好的代码将产生大致相同的性能,无论语言是静态的还是动态的,程序的,面向对象的或功能性的,命令性的或声明性的,懒惰的或严格的,纯洁或不纯洁.
事实上,我建议系统的性能完全取决于快速完成所花费的金额,并且完全独立于任何特定的打字规则,编程范例或语言.
以Smalltalk,Lisp,Java和C++为例.他们都是,或在过一个点,将首选高性能的代码语言.他们都具有巨大的数额花费在他们的工程和研究的人,几个世纪以来,使他们快.所有这些都具有高度调整的专有商业高性能执行引擎.鉴于大致相同的问题,由大致相当的开发人员实施,它们的表现大致相同.
其中两种语言是动态的,两种是静态的.Java很有趣,因为虽然它是一种静态语言,但大多数现代高性能实现实际上都是动态实现.(事实上,几个现代高性能JVM实际上是伪装的Smalltalk VM,源自Smalltalk VM或由Smalltalk VM公司编写.)Lisp也很有趣,因为虽然它是一种动态语言,但也有一些(尽管不是很多) )静态高性能实现.
我们甚至还没有开始谈论其余的执行环境:现代主流操作系统,主流CPU和主流硬件架构都严重偏向静态语言,以至于对动态语言充满敌意.鉴于现代主流执行环境几乎是动态语言的最坏情况,它们的实际表现非常令人惊讶,人们只能想象在不太恶劣的环境中的表现会是什么样子.
ewe*_*nli 17
首先,你必须澄清你是否考虑
通常我们的意思
,但这不是必要的.
类型信息可以帮助VM更快地调度消息,而不是类型信息,但是差异往往会随着检测单态呼叫站点的VM中的优化而消失.请参阅本文中有关动态调用的 "性能考虑"一节.
编译与解释与字节码JIT之间的争论仍然存在.有人认为字节码JIT比常规编译更快地执行,因为由于在运行时收集了更多信息,编译更准确.阅读有关JIT的维基百科条目,以获得更多信息.解释语言确实比两种形式或编译中的任何一种都慢.
我不会进一步争论,并开始激烈的讨论,我只想指出两者之间的差距往往越来越小.您可能遇到的性能问题可能与语言和VM无关,但由于您的设计原因.
编辑
如果你想要数字,我建议你看看计算机语言基准.我发现它很有见地.
在指令级,动态类型语言的当前实现通常比静态类型语言的当前实现慢.
然而,这并不一定意味着程序的实现在动态语言中会变慢 - 有很多记录在案的情况下,同一个程序以静态和动态语言实现,动态实现变得更快.例如,这项研究(PDF)给各种语言的程序员带来了同样的问题,并对结果进行了比较.Python和Perl实现的平均运行时间比C++和Java实现的平均运行时更快.
有几个原因:
1)代码可以用动态语言更快地实现,留出更多的时间进行优化.
2)高级数据结构(地图,集等)是大多数动态语言的核心部分,因此更有可能被使用.由于它们是语言的核心,因此它们往往得到高度优化.
3)程序员技能比语言速度更重要 - 没有经验的程序员可以用任何语言编写慢速代码.在上面提到的研究中,每种语言中最快和最慢的实现之间存在几个数量级的差异.
4)在许多问题域中,执行速度由I/O或语言外部的一些其他因素支配.
5)算法选择可以使语言选择相形见绌.在"More Programming Pearls"一书中,Jon Bentley为一个问题实现了两种算法 - 一种是O(N ^ 3),并在Cray1上以优化的fortran实现.另一个是O(N)并在BASIC上用TRS80家用微型机实现(这是在20世纪80年代).N> 5000时,TRS80的表现优于Cray 1.