回归ksh

概述这些天写了一些脚本，用的是groovy。对于Java程序员而言，较之于linux shell，自然是写groovy script (gsh)来的得心应手。的确，写的很快，几乎是分分钟搞定。但执行的时候就不那么迅速了，看上去很简单的任务（根据给定的参数和模板生成新的代码）居然用时要近两秒。虽然两秒可以接受，但毕竟反映出gsh的问题：vm的初始化！ 就java和groovy本身“运行速度”而言，显然要

这些天写了一些脚本，用的是groovy。对于Java程序员而言，较之于linux shell，自然是写groovy script (gsh)来的得心应手。的确，写的很快，几乎是分分钟搞定。但执行的时候就不那么迅速了，看上去很简单的任务（根据给定的参数和模板生成新的代码）居然用时要近两秒。虽然两秒可以接受，但毕竟反映出gsh的问题：vm的初始化！

就java和groovy本身“运行速度”而言，显然要比bash/ksh之类的脚本语言快，但不幸的是，论“起跑速度”，jvm简直是龟速。所以，一旦写出大量调用其它gsh脚本或是在应用时可能要递归调用的gsh，那么所有的时间都会浪费在不断启动的jvm进程上（每次半秒）。唯一(I Could be wrong)避免这种浪费的方法是将其它需要被调用的gsh都写成类的结构然后在jvm启动的时候加载这些类，仅仅以脚本方式调用本地程序，但这种方法的后果显然是背离了脚本编程的迅捷，变成了“真正”的编程。

于是，选择就变得很少：1. 继续groovy，不写递归结构，不写循环调用；2. shell和groovy混搭，大动作用groovy，比较频繁使用的选shell。

因此，在遇到真正的问题之前，我回归了传统：ksh。

总结

以上是内存溢出为你收集整理的回归ksh全部内容，希望文章能够帮你解决回归ksh所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。