smalltalk - Cog VM 和间接变量访问

Question

有谁知道 Pharo 和 Squeak 的 Cog VM 是否能够使用如下访问器优化简单的间接变量访问:

SomeClass>>someProperty
    ^ someProperty
SomeClass>>someSecondProperty
    ^ someSecondProperty

只返回一个实例变量，因此方法如下:

SomeClass>>someMethod
    ^ self someProperty doWith: self someSecondProperty

不会比这样的方法慢:

SomeClass>>someMethod
    ^ someProperty doWith: someSecondProperty

我做了一些基准测试，它们的速度似乎大致相当，但我很好奇熟悉 Cog 的人是否知道这一点，因为如果存在差异(无论多么微小)，那么可能会出现一些情况很少有不合适的地方。

Answer 1

现在有一点成本，但它太小了，你不应该打扰。如果您想要性能，您愿意更改代码的其他部分，而不是实例变量访问。

快速板凳:长椅 ^ { [ iv 你自己 ] 板凳。 [ 自己 iv 自己 ] 板凳 }=> #('每秒 52,400,000 个。''每秒 49,800,000 个。')差别看起来并没有那么大。

一旦 jitted 并执行一次，不同之处在于“self iv”除了获取实例变量值之外，还执行内联缓存检查、cpu 调用和 cpu 返回。调用和返回指令很可能会被 CPU 预期，但不会真正执行。所以这是关于内联缓存检查，这是一个非常便宜的操作。

开发中的内联编译器将添加的是，cpu 调用和返回实际上将通过内联删除，这将覆盖 cpu 未预料到的情况。此外，根据具体情况，内联缓存检查可能会也可能不会被删除。

有一些细节，例如 getter 方法需要编译为 native 代码，这会占用机器代码区域的空间，这可能会增加机器代码区域垃圾收集的数量，但这比内联缓存检查开销更有趣。

简而言之，现在的开销非常非常小，但将来开销会减少。

克莱门特