top
按 M （ shift+m ）

简单优化一下：

find | while read x; do file $x; done | awk .....

总结：
1. 文件缓存没必要，增加大量 IO
2. 既然用了 awk，直接使用 awk 解决所有判断、输出的问题，不要用过多的指令（重复 fork 非常多）
3. 还是要看下到底哪一步耗时才好优化。

awk 启动慢，因为你启动了太多次，将 file 的结果合并到一起传给 awk 按行处理即可。

重名就瞎了

看了最新的补充才看懂是在说什么……你们怎么就一下子明白了楼主的意思的？？？

@mcfog
但是 B 没实现 Func 的话，断言会失败啊。
所以 B 实现了 Func，那么断言之后调用 Func 还是 B 的 Func 吧？

没办法，你只能自己洗一遍洗成结构化的数据再去处理。
ES 可以，但一天上亿需要的集群不小了。
或者直接丢 hive，但是也要预处理，比 ES 预处理简单，但是分析起来麻烦。

A 实现了接口 B，A 有一个实例叫 b
b.(B).Func() 么这不就是？？？

没看懂楼主想说什么……
本来 b 就可以直接 b.Func() 啊？？？

@runze
『』「」<>《》 你要哪个？

[] ［］ [] 你要哪个？都可以啊

怎么下一波？？？

哈哈哈哈哈哈哈，不会不要紧，学两天基本就掌握了，但是有人就是呵呵。

不能。不可能的。

可以退啊，动物园门口。退卡退押金余额。

pho 每个请求起进程的方式这里确实没必要优化。
如果是 fpm 常驻进程就有区别。

你对比下两个字符串不久看到是哪里不一样了？？？

@mcfog
我觉得能写好 promise 的人一定能用 async/await，但是不会用 async/await 的肯定 promise 也不懂。
而且还有 async 属于新标准，很多人不一定知道并且用过……

@flowfire
async await 收益巨大，傻子也能写异步了。promise 真的太难了。
try 相比之下收益太小了，错误处理还是要写，只能包一个 func （这点真的很蠢……），而且现在很多 MustFunc 写法。总之看起来就不是个好的解决方案，况且它没解决根本问题。

刚好前几天看了眼，感觉 try 根本就没解决问题，只是看起来 /写起来稍微简单了点，所以被拒是正常的。