https://github.com/y-ui/laravel-running-ti...
可以先array_filter下

$sortedPath  = array_filter($sortedPath );
foreach ($sortedPath as $key => &$value) {
            //if (empty($value)) {
            //    unset($sortedPath[$key]);
            //    continue;
            //}
            $value = [$value, $key];
        }

@lovecn 是的，这样性能更好，代码也更好看~感谢~

可以，哈哈，学会了 file() 的用法 :stuck_out_tongue_winking_eye:

改了一下 RunningTimeCommand.php，使用了 fgets 配合 yield 减少内存的使用。同时 $pathTimes 只记录比较、统计的结果，不记录所有的数据，减少内存使用。

https://github.com/y-ui/laravel-running-ti...

修改了一下 pathTime 来兼容使用 yield 的写法.

没使用 yield 之前

使用 yield

@ruby 非常优秀的想法，内存使用大大减少，不过真实场景下的计算时间并不像你测试的那样也减少了，我用我的真实数据跑了一下，计算时间增加了大概 34%左右，应该和每行日志的长度有关，内容越多，fgets导致的额外时间开销越多，我用最简单的日志测试计算时间增加15%，总体来说这个时间换来的内存节约非常划算 :+1:

没有yield:

使用yield:

@y-ui 时间增加应该是的。昨天一不小心写了个 bug 进去，php artisan running-time 没有统计到最小时间，提了个 PR

@ruby 哈哈，改出来的BUG不少呢，你这个pr我就不合并了

@y-ui 还有什么其他 bug 吗 :joy:

@ruby

• path统计数量不正确
• 你说的这个最小时间问题
• 延迟批量写入功能不能用了
• 检查目录是否存在不要每次都检查 ，延迟写入模式只需要在写入文件时检查，减少IO

我merge了你的第一个pr，然后修复了以上BUG，并且加入了 --lessMemory 选项使用你的读取文件方式。
默认还是使用file函数读取，但是使用yield，有效减少了多个日志文件统计时的内存开销，因为数据越多使用fgets花费时间越多，400W数据时 时间差达到了100%

请教一个问题，接口响应时间按道理应该是请求结束时间－请求开始时间，为什么我看你的源代码是请求开始时间－依赖包加载的时间尼

我也整理了一个类似的，支持cli和web端的https://github.com/alicfeng/laravel-runtim...

@returnfalse 接口响应时间应该是服务器
@returnfalse 这个并不是中间件加载的时间，中间件有两种执行方式，一种是处理请求前，一种是返回请求后，我这里就是返回请求后执行，所以实际相当于请求结束的时间，具体可以看laravel的中间件文档

@y-ui 嗯，明白了，一看文档我就懂了，谢谢，还是要交流，感觉有时候还是有知识盲区

有个疑问 执行php artisan vendor:publish --provider='RunningTime\RunningTimeServiceProvider' 没有生成配置文件runningtime.php

可以 在数据库中保存这个api响应时间吗