问哪个更快，Clojure和ClojureScript (为什么)？

EN

如果不引用特定的基准任务(甚至是Clojure或ClojureScript的特定版本)，就很难准确回答这个问题。

话虽如此，在大多数情况下，我希望Clojure会更快一些。原因：

• Clojure通常会编译成静态代码，因此它实际上不会在运行时执行任何动态查找。这一点非常重要:高性能代码通常会生成与静态类型Java非常相似的字节码。问题似乎是做了一个错误的假设，即动态语言必须在运行时进行动态方法查找:情况并不总是这样(在Clojure中通常也不是)
• JIT设计得非常好，我相信它目前仍然比JavaScript JIT好一点，尽管V8有多好。
• 如果你需要并发或需要利用多核，那么显然没有什么竞争，因为JavaScript是Clojure编译器比ClojureScript更成熟，并在最近几年进行了大量的性能调优工作(包括原语支持、协议等)

当然，可以用任何语言编写快代码或慢代码。这将产生比语言实现之间的根本差异更大的差异。

更根本的是，您在Clojure和ClojureScript之间的选择在任何情况下都不应该与性能有关。两者都提供了令人信服的生产力优势。主要的决定因素应该是：

Clojure

• 如果您想在web上运行，请使用您想要在JVM环境中的服务器上运行的ClojureScript

• If，请使用

实际上，V8是用C++编写的。然而，做的事情基本上和JVM是一样的，JVM是用C编写的。V8 JITs Javascript代码并执行JIT的代码。同样，JVM JIT编译(或hotspot编译)字节码(而不是Java)并执行生成的代码。

字节码不像Java那样是静态的。事实上，它可以是非常动态的。另一方面，Java大多是静态的，将Java与字节码混为一谈是不正确的。java编译器将Java源代码转换为字节码，JVM执行该字节码。有关更多信息，我建议您查看John Rose的博客(example)。这里有很多好的信息。此外，尝试查找Cliff Click的talks (如this one)。

同样，Clojure代码被直接编译为字节码，然后JVM对该字节码执行相同的过程。编译Clojure通常在运行时完成，这不是最快的过程。同样，Clojurescript到Javascript的转换也不是很快。V8将Javascript转换成可执行文件的速度显然相当快。Clojure可以提前编译成字节码，这可以消除大量的启动开销。

正如您所说，说JVM解释字节码也是不正确的。1.0版本早在17年前就做到了！

传统上，有两种编译模式。第一种模式是JIT (Just in Time)编译器。其中字节码被直接翻译成机器代码。Java的JIT编译执行得很快，并且不会生成高度优化的代码。它运行正常。

第二种模式称为hotspot编译器。hotspot编译器非常复杂。它以解释模式快速启动程序，并在程序运行时对其进行分析。当它检测到热点(代码中频繁执行的点)时，它将编译这些热点。而JIT编译器必须很快，因为除非JIT‘’ed，否则什么都不会执行。hotspot编译器可以花费额外的时间来优化它正在编译的代码。

此外，它可以在以后返回并重新访问该代码，并在必要和可能的情况下对其应用更多的优化。这是hotspot编译器可以开始击败编译的C/C++的地方。因为它具有代码的运行时知识，所以它可以应用静态C/C++编译器无法实现的优化。例如，它可以内联虚拟函数。

Hotspot还有另一个功能，据我所知，其他环境都没有这个功能，如果需要的话，它还可以取消优化代码。例如，如果代码不断地采用单个分支，并且该分支经过优化，并且运行时条件发生变化，迫使代码向下移动另一个(未优化的)分支，则性能突然变得非常糟糕。Hotspot可以取消优化该函数，并再次开始分析，以找出如何使其运行得更好。

hotspot的一个缺点是启动有点慢。Java 7 JVM中的一个变化是合并了JIT编译器和hotspot编译器。虽然这种模式是新的，但它不是默认的，但是一旦它是初始启动，它就应该是好的，然后它就可以开始advanced optimizations，这是JVM非常擅长的。

干杯!

与其说这是一个答案，不如说是一个历史评论: HotSpot VM和V8 js引擎的起源都可以追溯到Sun Microsystems的Self项目，我认为该项目是许多技术的原型，使它们能够像现在这样快速运行。比较两者时需要考虑的问题。我本想发表这篇评论的，但声誉系统阻止了我。