我什么时候/为什么要使用 Groovy 的 @CompileStatic? [英] When/why would I want to use Groovy's @CompileStatic?

问题描述

我读过这个:http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html，以及:如果我也使用 Java 7，我应该使用 Groovy 的 @CompileStatic 吗，并且知道肯定会有性能改进，但是那吗?我不明白 @CompileStatic 到底是做什么的.

I've read this: http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html, and this: Should I use Groovy's @CompileStatic if I'm also using Java 7, and understand there are certainly performance improvements to be had but is that it? I don't understand exactly what @CompileStatic does.

是否有某些类可以轻松添加 @CompileStatic?我哪里不想要它?

Are there certain classes on which adding @CompileStatic is a no-brainer? Where would I not want it?

推荐答案

引用我对 如果我也使用 Java 7，我应该使用 Groovy 的 @CompileStatic:

虽然比普通的 Groovy 快，但它只能编译 Groovy 的一个子集，并且行为略有不同.尤其是所有动态功能都不再可用.

While faster than normal Groovy, it can compile only a subset of Groovy and behaves a bit different. Especially all the dynamic features are not available anymore.

所有 MOP 都将被绕过.构建器通常不会工作，有些对编译器进行了扩展以允许它们通过.此外，在编译时使用静态类型选择方法，而 Groovy 通常使用在运行时可用的方法和运行时类型.这可能会导致调用不同的方法.

All of the MOP will be bypassed. Builders won't work in general, some have extensions to the compiler to allow them passing though. Also methods are selected at compile time using static types, while Groovy normally uses the methods available at runtime and the runtime types. This can result in different methods being called.

当然@CompileStatic 也提供了一些安全性，因为在运行时验证程序是编译器的任务.但由于静态信息注定是不完整的，因此永远不可能有 100% 的安全性.

Of course @CompileStatic also provides some security, since it is the tasks of a compiler to verify programs at runtime. But since static information is doomed to be incomplete, there can never be a 100% security.

那么它在哪里是显而易见的......好吧......例如POGO，因为它们通常不包含那么多代码.当然还有通过复制粘贴从 Java 移植到 Groovy 的类.

So where is it a no-brainer... well... POGOs for example, since they don't usually contain all that much code. And of course for classes ported from Java to Groovy by copy&paste.

我想要它在哪里?嗯，目前可能在 Android 上，因为代码大小有影响，并且静态编译的代码更紧凑.否则我个人完全不使用@CompileStatic.这更像是一个品味问题.在某些情况下，紧密循环会提高性能，但这需要您首先通过分析您的应用程序来进行识别

Where would I want it? Well, currently probably on Android, since there the code size has an impact and the static compiled code is more compact. Otherwise I personally am fine with not using @CompileStatic at all. This is more a matter of taste. In some cases there is a performance improvement for tight loops, but that requires you going and identifying by profiling your application first

这篇关于我什么时候/为什么要使用 Groovy 的 @CompileStatic?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！