加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

回归ksh

发布时间:2020-12-14 17:04:34 所属栏目:大数据 来源:网络整理
导读:这些天写了一些脚本,用的是groovy。对于Java程序员而言,较之于linux shell,自然是写groovy script (gsh)来的得心应手。的确,写的很快,几乎是分分钟搞定。但执行的时候就不那么迅速了,看上去很简单的任务(根据给定的参数和模板生成新的代码)居然用时

这些天写了一些脚本,用的是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。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读