为什么代理模式这么慢？

Question

至少在java中，代理模式有很多开销——我不记得确切的数字，但是当包装微小方法时，代理花费的时间大约是包装方法的50倍。例如，这就是为什么 java.awt.image.BufferedImage.setRGB 和 getRGB 确实很慢的原因；大约有三个代理包装了实际的byte[]。

为什么50次？！为什么代理不将时间加倍？

---

Edit: =(

就像往常一样，我得到了一堆答案，告诉我我的问题是错误的。它不是。查看 BufferedImage 或其他一些真实的代理模式，而不是那些微基准。事实上，如果您必须对 BufferedImage 进行大量像素操作并且了解其结构，则可以通过手动撤消代理来实现上述巨大的加速；请参阅此答案。

哦，还有这是我的来源50 倍。正如文章所详述的，当代理所包装的内容需要很长时间时，它们不会受到明显的惩罚，但是如果您包装一个很小的方法，它们确实会产生巨大的痛苦开销。

Answer 1

我不知道“50次”这个数字从何而来，但它很可疑。特定代理可能比它所代理的代理明显慢，具体取决于每个代理正在做什么，但据此概括说“代理模式太慢了”就是采取这是逻辑上非常戏剧性且非常值得怀疑的飞跃。

试试这个：

Thingy.java:

public class Thingy
{
    public int foo(int param1, int param2)
    {
        return param2 - param1;
    }
}

ThingyProxy.java:

public class ThingyProxy
{
    Thingy thingy;

    public ThingyProxy()
    {
        this.thingy = new Thingy();
    }

    public int foo(int param1, int param2)
    {
        return this.thingy.foo(param1, param2);
    }
}

WithoutProxy.java:

public class WithoutProxy
{
    public static final void main(String[] args)
    {
        Thingy t;
        int sum;
        int counter;
        int loops;

        sum = 0;
        t = new Thingy();
        for (loops = 0; loops < 300000000; ++loops) {
            sum = 0;
            for (counter = 0; counter < 100000000; ++counter) {
                sum += t.foo(1, 2);
            }
            if (sum != 100000000) {
                System.out.println("ERROR");
                return;
            }
        }
        System.exit(0);
    }
}

WithProxy.java:

public class WithProxy
{
    public static final void main(String[] args)
    {
        ThingyProxy t;
        int sum;
        int counter;
        int loops;

        sum = 0;
        t = new ThingyProxy();
        for (loops = 0; loops < 300000000; ++loops) {
            sum = 0;
            for (counter = 0; counter < 100000000; ++counter) {
                sum += t.foo(1, 2);
            }
            if (sum != 100000000) {
                System.out.println("ERROR");
                return;
            }
        }
        System.exit(0);
    }
}

简单试验我的机器：

$ time java WithoutProxy 

real    0m0.894s
user    0m0.900s
sys     0m0.000s

$ time java WithProxy

real    0m0.934s
user    0m0.940s
sys     0m0.000s

$ time java WithoutProxy 

real    0m0.883s
user    0m0.850s
sys     0m0.040s

$ time java WithProxy

real    0m0.937s
user    0m0.920s
sys     0m0.030s

$ time java WithoutProxy 

real    0m0.898s
user    0m0.880s
sys     0m0.030s

$ time java WithProxy

real    0m0.936s
user    0m0.950s
sys     0m0.000s

慢一点？是的。慢 50 倍？不。

现在，对 JVM 进行计时非常困难，并且像上面这样的简单实验必然是值得怀疑的。但我认为可能会出现 50 倍的差异。

编辑：我应该提到，上面的循环数量非常非常少，发布的数字如下：

real    0m0.058s
user    0m0.040s
sys     0m0.020s

...这让您了解环境中虚拟机的启动时间。例如，上面的时间大部分不是虚拟机启动，实际执行时间只有一微秒的差异，它们主要是执行时间。

Answer 2

当代码被编译为本机代码时，字节数组访问将类似于 3 1 周期指令（只要源数据和目标数据在缓存中是热的，并且未对齐的字节访问不会受到惩罚。YMMV 取决于平台）。

添加方法调用来存储四个字节将（取决于平台，但类似这样）添加将寄存器推送到堆栈、调用指令、数组访问指令、返回指令以及从堆栈中弹出寄存器。将为每一层或代理添加推送/调用/返回/弹出序列，并且这些指令大多不会在 1 个周期内执行。如果编译器无法内联这些方法（这很容易发生），您将遭受相当大的惩罚。

代理添加了在颜色深度等之间进行转换的功能，从而增加了额外的开销。

此外，编译器还可以进一步优化顺序数组访问（例如，将存储操作转变为多个字节访问操作 - 一次最多 8 位，同时仍然只需要 1 个周期），而代理调用则使这变得困难。

50x 听起来有点高，但并非不合理，具体取决于实际代码。

BufferedImage 尤其会增加大量开销。虽然代理模式本身可能不会增加明显的开销，但 BufferedImage 的使用可能会增加。请特别注意 setRGB() 是同步的，这在某些情况下可能会产生严重的性能影响。

Answer 3

我看到它们有所作为的一个地方是在不执行任何操作的代码上。 JVM 可以检测到不执行任何操作的代码并消除它。但是，使用方法调用可能会混淆此检查，并且代码不会被消除。如果您在此类示例中比较使用和不使用方法的时间，您可以获得您想要的任何比率，但是如果您查看无方法测试的进行情况，您会发现代码已被消除并且运行速度快得不合理。例如，每个循环比一个时钟周期快得多。

---

普通方法是内联的，例如 getter 和 setter。它们根本不会对性能产生影响。我非常怀疑真实程序声称的 50 倍。当正确测试时，我希望更接近无差异。