Question

我知道优化的规则＃1是：不要这样做！但我认为这是一个简单的问题，如果我现在开始使用更快的方法，那么当我完成时我可以节省大量的cpu时间。

我正在制作一个RPG，让我们说这是自定义类的一部分：

public class Baddie{

    int health;
    int magic;

    public Baddie(int health, int magic){
        this.health = health;
        this.magic = magic;
    }

    public int getHealth(){
        return health;
    }

现在，我的问题的答案可能是“没有区别”，这对我很好..我只是想知道。使用字段访问来获取Baddie的健康状况是否更快：

//Somewhere in the main thread, I get an instance of Baddie..
Baddie b = getScaryBadGuy();
int baddieHealth = b.health;

或者使用return方法更快？

int baddieHealth = b.getHealth();

Answer 1

从Designing for Performance复制并粘贴：

避免内部吸气人/设定者


在像C ++这样的本地语言中   使用吸气剂的常见做法（例如i   = getCount（））而不是直接访问该字段（i = mCount）。这是   C ++的一个很好的习惯，因为   编译器通常可以内联   访问，如果你需要限制或   调试字段访问你可以添加   代码随时。

在Android上，这是一个坏主意。   虚方法调用很昂贵，   实例领域要多得多   查找。遵循是合理的   常见的面向对象编程   练习并有吸气剂和制定者   在公共界面，但在一个   你应该总是访问字段   直接

没有JIT，直接进行现场访问   大约比调用一个快3倍   琐碎的吸气剂。随着JIT（在哪里   直接现场访问便宜   访问本地），直接领域   访问速度比快7倍   调用一个微不足道的吸气剂。这是   在Froyo中是真的，但会在改进   JIT内联获取者的未来   方法

Answer 2

表现永远是相对的。从百分比或因素的角度来考虑通常会更好。如果某事需要一微秒，也许这就是很多，也许它什么都没有。这取决于您每秒需要执行多少次。这是过早优化的主要原因，不知道是否存在问题。

Answer 3

如果可以，编译器将进行优化。这是过早优化的完美示例。使用代码中有意义的东西。不要担心“储蓄周期”。这可能会或可能不会保存的2-3个周期超过任何其他操作所需的数百万个周期。

Answer 4

IMO它更像是一个设计问题，而不是优化问题。在你真正需要从课堂外访问它们之前，我建议不要编写/生成任何getter或setter。这往往会使耦合尽可能低。

或者，默认情况下将这些getter / setter设为私有将具有相同的结果，但它的代码更多，没有任何实际好处。

优化：访问字段与方法

4 个答案: