禁用 Ruby 1.9.x 的 YARV 编译器
使用 ruby 1.9.x 与 1.8.7 从命令行运行我的规范之间的应用程序启动时间存在非常明显的差异。我的应用程序使用 ruby 1.8.7 启动的速度比使用 ruby 1.9.1 或 1.9.2 快得多。应用程序启动差异约为 18 秒。我的应用程序在 1.8.7 中初始化大约需要 5 秒，在 1.9.1 和 1.9.2 中初始化大约需要 23 秒。
应用程序初始化时间对于生产来说并不是什么大问题，但对于 BDD 开发来说却是一个非常大的问题。每次我更改代码并运行规范时，每次迭代我都必须额外等待 18 秒。
我假设这个应用程序初始化时间归因于我的应用程序初始化时 YARV 编译字节码。
我关于 YARV 减慢应用程序初始化的说法正确吗？有没有办法在命令行上禁用 YARV。如果能够仅在运行规范时禁用 YARV，那就太好了。
There is a very noticeable difference in application initiation time between running my specs from the command line with ruby 1.9.x vs. 1.8.7. My application initiates much faster with ruby 1.8.7 than with ruby 1.9.1 or 1.9.2. The application initiation difference is approximately 18 seconds. It takes about 5 seconds for my app to initialize with 1.8.7 and 23 seconds with 1.9.1 and 1.9.2.
Application initialization time is not a big deal for production, but it is a very big deal for BDD development. Every time I change my code and run my specs, I have to wait an additional 18 seconds per iteration.
I assume this application initialization time is attributed to YARV compiling bytecode as my application initializes.
Am I right about my YARV slowing down my application initialization, and is there a way to disable YARV on the command line. It would be very nice to be able to disable YARV only when I am running my specs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
YARV 是一个纯 Ruby 编译器。如果禁用它，就什么都没有了。
更准确地说：YARV 是一种多阶段实现，其中每个阶段都是单模式。它由 Ruby 到 YARV 编译器和 YARV 解释器组成。如果删除编译器，唯一剩下的就是 YARV 字节码解释器。除非您想开始用 YARV 字节码编写应用程序，否则该解释器对您没有多大用处。
这与 JRuby 和 IronRuby 等混合模式实现形成鲜明对比，它们在单个阶段内实现多种执行模式（特别是编译器和解释器）。如果您关闭 JRuby 或 IronRuby 中的编译器，您仍然可以使用可用的执行引擎，因为它们都还包含解释器。事实上，JRuby 实际上是从纯解释器开始的，后来添加了编译器，而 IronRuby 最初是纯编译器，他们添加了一个解释器，因为与您遇到的问题相同。我们看到：编译单元测试简直就是浪费时间。
目前 Ruby 1.9 唯一的解释实现是 JRuby。当然，您需要处理整个 JVM 开销。您能做的最好的事情就是尝试让 JRuby 启动的速度有多快（使用 http://CI.JRuby.Org/snapshots/ 因为此时此刻正在大力研究 1.9 支持和启动时间）使用一些非常快速启动的面向桌面的 JVM（如 IBM J9）或尝试 JRuby Nailgun 支持，使 JVM 在后台运行。
您还可以尝试摆脱 RubyGems，它通常会占用大量启动时间，尤其是在 YARV 上。 （使用
--disable-gem命令行选项可以真正摆脱它。）YARV is a pure Ruby compiler. If you disable it, there's nothing left.
More precisely: YARV is a multi-phase implementation, where each of the phases is single-mode. It consists of a Ruby-to-YARV compiler and a YARV interpreter. If you remove the compiler, the only thing you are left with is the YARV bytecode interpreter. Unless you want to start writing your app in YARV bytecode, that interpreter is not going to be of much use to you.
This is in contrast to mixed-mode implementations such as JRuby and IronRuby which implement multiple execution modes (in particular, both a compiler and an interpreter) within a single phase. If you turn off the compiler in JRuby or IronRuby, you are still left with a usable execution engine, because they both also contain an interpreter. In fact, JRuby actually started out as a pure interpreter and added the compiler later and IronRuby started out as pure compiler and they added an interpreter exactly because of the same problem that you are seeing: compiling unit tests is simply a waste of time.
The only interpreted implementation of Ruby 1.9 right now is JRuby. Of course, there you have the whole JVM overhead to deal with. The best thing you can do is try how fast you can get JRuby to start up (use the nightly 1.6.0.dev builds from http://CI.JRuby.Org/snapshots/ since both 1.9 support and startup time are heavily worked on right this very moment) using either some very fast starting desktop-oriented JVM like IBM J9 or try JRuby's Nailgun support, which keeps a JVM running in the background.
You could also try to get rid of RubyGems, which generally eats up quite a lot of startup time, especially on YARV. (Use the
--disable-gemcommandline option to truly get rid of it.)目前无法禁用 YARV，因为 MRI 1.9 仅包含虚拟机，而不包含解释器。对于核心团队来说，维护两者的工作量太大了。
将来可能会有办法缓存 YARV 生成的字节码（就像 Rubinius 所做的那样）。目前无法通过 Ruby 加载此类字节码（请参阅 #971)，但您可以轻松编写一个 C 扩展来完成它。
不过，我想说 18 秒太长了，而且可能是一个错误。我知道 ruby-core 上有一些线程讨论了
require的缓慢性；也许你会在那里发现一些有趣的东西！There's currently no way to disable YARV, simply because MRI 1.9 only includes the virtual machine, and not an interpreter. Maintaining both would be way too much job for the core team.
In the future there will probably be ways to cache the bytecode YARV generates (like Rubinius does). At the moment there is no way to load such bytecode through Ruby (see #971), but you could easily write a C extension which accomplishes it.
However, I would say that 18 seconds is way too much and it's probably a bug. I know there are some threads at ruby-core which discusses the slowness of
require; maybe you find something interesting there!1.9.2 的下一个 RC 可能会更快，因为它不会预加载 $: 和所有 gem lib 目录。
the next RC of 1.9.2 out might be faster as it doesn't preload $: with all your gem lib dirs.