也许是一个新手的问题，但如果你从不问你永远不会知道
在 RoR 应用程序上使用 Stripe 的 Sorbet ( https://sorbet.org/ ) 是否可以潜在地提高应用程序的性能？（性能意味着响应时间，而不是鲁棒性\运行时错误率）
我读了一些动态类型语言（在这种情况下尤其是 Javascript），发现如果我们继续发送一些函数（foo例如）相同类型的对象，引擎会对那个函数做一些优化工作，所以当它是用相同的类型再次调用，那里的解释工作会更快。
我想也许 ruby 解释器做了类似的工作，这可能意味着类型检查可能会提高解释速度
我想也许 ruby 解释器做了类似的工作，这可能意味着类型检查可能会提高解释速度
它还没有，但有可能有一天会建立这个。与为计算机（编译器）构建类型系统相比，Sorbet 的目标是为人们构建类型系统。它可能会引入一些性能开销，但是当 Stripe 在生产中运行它时，我们会对其进行检查。在内部，如果开销大于 CPU 时间的 7%，我们会分页。
我阅读了一些动态类型语言（在这种情况下尤其是 Javascript），发现如果我们继续发送一些函数（例如 foo）相同类型的对象，引擎会对该函数进行一些优化工作，所以当它用相同的类型再次调用，那里的解释工作会更快。
是的，这是可以做到的。您所描述的是即时（JIT）编译器中的常见优化。您似乎引用的技术使用运行时分析，实际上是一种常见的替代技术，允许在没有类型系统的情况下实现此结果。还值得注意的是，构建良好的 JIT 可以比类型系统更频繁地执行此操作，因为类型系统对可能发生的事情进行编码，而分析和 JIT 可以针对实践中实际发生的事情进行优化。
也就是说，构建 JIT 通常比构建在线编译器需要更多的工作，因此，根据想要投入的加速 Ruby 的投资量，使用构建 JIT 或使用类型可以证明在不同的现实世界约束下更好.
我想也许 ruby 解释器做了类似的工作，这可能意味着类型检查可能会提高解释速度
总结上一段，Sorbet 类型系统目前并没有加速 Ruby，但也没有减慢太多。类型系统确实可以用来加速语言，但它们不是你唯一的工具，分析和 JIT 编译是主要的竞争对手。
您正在谈论的优化更多地适用于为 ruby 运行时工作的 JIT。
一般来说，Sorbet 通过引入类型接口或方法签名来实现类型安全。它们启用在部署应用程序之前应用的静态类型检查，以消除“类型错误”。
sorbet 带有一个运行时组件，可以在可运行的应用程序中在运行时强制执行类型检查，但是这些会降低应用程序的性能，因为它们会包装方法调用以检查正确的类型https://sorbet.org/docs/运行时#runtime-checked-sig-s