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

查看:168
本文介绍了什么时候/为什么要使用Groovy的@CompileStatic?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已阅读以下内容: http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html ,如下:

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?

推荐答案

引用我对

To cite my part of my answer to Should I use Groovy's @CompileStatic if I'm also using Java 7:

虽然它比普通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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆