从他们的网站http://www.playframework.org/documentation/1.0/faq
”
目前，Play堆栈中最大的CPU消耗者是基于Groovy的模板引擎。但是，由于Play应用程序易于扩展，因此如果需要提供很高的流量，这并不是真正的问题:您可以平衡多台服务器之间的负载。我们希望通过新的JDK7及其对动态语言的更好支持，在此级别获得性能提升。
”
因此，没有更好的选择吗？那JSP呢？
最佳答案
JSP是不可行的，因为每个JSP都可以编译为Servlet，并且Servlet API提供了与RESTful范式不兼容的服务器端 session 之类的功能。我们不想回到可扩展的服务器端 session 的黑暗时代，浏览器中的后退按钮问题，重新发布等。
Japid模板很有趣，但是它们没有强大的社区支持，甚至在创建剧本时甚至都不存在(尽管我不确定)。我尝试用Japid替代我自己的应用程序中的Groovy模板，并在JMeter测试中发现 yield 仅是很小的，最大 yield 只有10％。改善25％。
我想最后，这完全取决于您的可伸缩性要求和页面结构。我选择了应用程序90％的用例并进行了测试。对我来说，一点点改进并不能证明额外依赖项的额外成本是合理的(我希望将依赖项保持在最低限度以实现可维护性)。
Groovy模板通常不错或很慢。即使在闭包中，也要尽可能使用类型化的变量(而不是“def”)!将访问的属性的值保留在局部变量中。做合理的分页结果。然后，用手指指望GSP将来可以在groovy++上运行，您就完成了；)
对我而言，问题不在于他们为什么在观点中使用常规。也就是说，因为我宁愿在 Controller 层中也非常想念它。 Groovy将使对 Controller 行为的编码变得容易得多，恕我直言。
关于performance - 为什么玩!框架选择Groovy作为模板引擎，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6563861/