Julia 语言每次都会编译脚本，难道我们不能用 Julia 编译二进制文件吗？ 我尝试了一个带有 println 函数的小型 helloworld 脚本，julia 显示输出需要 2.3 秒！如果我们可以制作二进制文件而不是每次都编译会更好
更新：自从我提出这个问题以来，Julia 发生了一些变化。虽然我不再关注 julia 的更新，但因为我已经问过这个问题，如果您正在寻找类似的东西，请查看以下关注 julia 的人的答案和 cmets。
另外，很高兴知道现在加载脚本大约需要 150 毫秒。
【问题讨论】：
标签： julia
基诺的回答很准确，但也许我可以更详细地说明正在发生的事情以及我们计划对此做些什么。
目前只有LLVM JIT模式：
这就是即使在没有类型注释的情况下编写代码时 Julia 也能获得良好性能的原因：如果您调用 f(1)，您将获得专门用于 Int64 的代码——在 64 位系统上是 1 的类型；如果你调用f(1.0)，你会得到一个专门用于Float64的新版本——在所有系统上都是1.0的类型。由于函数的每个编译版本都知道它将获得什么类型，因此它可以以类似 C 的速度运行。您可以通过编写和使用“类型不稳定”函数来破坏这一点，这些函数的返回类型取决于运行时数据，而不仅仅是类型，但我们在设计核心语言和标准库时非常小心不要这样做。
大部分 Julia 都是自己编写的，然后经过解析、类型推断和 jitted，因此从头开始引导整个系统需要大约 15-20 秒。为了让它更快，我们有一个分阶段的系统，我们在其中解析、类型推断，然后在文件sys.ji 中缓存类型推断的 AST 的序列化版本。当您运行julia 时，该文件将被加载并用于运行系统。但是，sys.ji 中没有缓存任何 LLVM 代码或机器代码，因此每次 julia 启动时仍然需要完成所有 LLVM jitting，因此大约需要 2 秒。
这 2 秒的启动延迟非常烦人，我们有一个修复它的计划。基本计划是能够将整个 Julia 程序编译为二进制文件：可以运行的可执行文件或可以从其他程序调用的 .so/.dylib 共享库，就好像它们只是共享 C 库一样。二进制文件的启动时间将与任何其他 C 程序一样，因此 2 秒的启动延迟将消失。
附录 1： 自 2013 年 11 月起，Julia 的开发版本不再有 2 秒的启动延迟，因为它将标准库预编译为二进制代码。启动时间仍然比 Python 和 Ruby 慢 10 倍，因此还有改进的空间，但速度相当快。下一步将允许对包和脚本进行预编译，以便它们可以像 Julia 本身一样快速启动。
附录 2： 自 2015 年 6 月以来，Julia 的开发版本自动预编译了许多包，允许它们快速加载。下一步是静态编译整个 Julia 程序。
【讨论】：
julia -e "using DataFrames" 在我的机器上需要 21 秒。有没有办法解决这个问题？
julia v0.4的新特性，大大提高了模块加载时间。
目前 Julia JIT 在启动时编译其整个标准库。我们知道这种情况，目前正在努力缓存 LLVM JIT 输出以纠正这种情况，但在那之前，没有办法解决它（除了使用 REPL）。
【讨论】：