关于写入速度 about easyflash

[TeemoRZ]

补充一下LOG ，可以看到 写一个时长要3s多

[16:43:38.726]收←◆Flash Trigger a GC check after created ENV.

[16:43:38.936]收←◆Flash The remain empty sector is 948, GC threshold is 1.
214
[16:43:42.333]收←◆215
[16:43:45.726]收←◆216
[16:43:49.120]收←◆217
[16:43:52.517]收←◆218
[16:43:55.918]收←◆219
[16:43:59.320]收←◆220
[16:44:02.723]收←◆221
[16:44:06.131]收←◆222
[16:44:09.542]收←◆223
[16:44:12.956]收←◆Flash Trigger a GC check after created ENV.

[16:44:13.166]收←◆Flash The remain empty sector is 948, GC threshold is 1.
224
[16:44:16.576]收←◆225
[16:44:19.980]收←◆226
[16:44:23.388]收←◆227
[16:44:26.799]收←◆228
[16:44:30.211]收←◆229
[16:44:33.627]收←◆230
[16:44:37.044]收←◆231
[16:44:40.464]收←◆232
[16:44:43.888]收←◆233
[16:44:47.315]收←◆Flash Trigger a GC check after created ENV.

[16:44:47.525]收←◆Flash The remain empty sector is 948, GC threshold is 1.
234
[16:44:50.949]收←◆235

[armink]

会不会跟 SPI 驱动有关系，先抓一下 SPI 波形分析一下吧

[TeemoRZ]

会不会跟 SPI 驱动有关系，先抓一下 SPI 波形分析一下吧

这个SPI驱动和之前 直接驱动flash是同一个驱动，是直接的hal库 api；
之前写入速度几乎在100ms左右

[TeemoRZ]

会不会跟 SPI 驱动有关系，先抓一下 SPI 波形分析一下吧

这个SPI驱动和之前 直接驱动flash是同一个驱动，是直接的hal库 api；
之前写入速度几乎在100ms左右

另外一个发现，随着写入次数的增加，写入的速度越来越慢

[TeemoRZ]

是否有相关的测试benchmark？

[armink]

4.0 在减少 RAM 占用的条件下牺牲了环境变量操作的速度，如果对速度要求苛刻，可以先使用 3.0 版本。

接下来会对 4.0 的速度问题重点优化，如果兴趣欢迎加入进来一起优化。

[TeemoRZ]

我调试了一下发现，每次都会执行如下代码，检测 所有env，这里消耗大部分时间
/* search all ENV /
while ((env->addr.start = get_next_env_addr(&sector, env)) != FAILED_ADDR) {
read_env(env);
/ iterator is interrupted when callback return true */
if (callback(env, arg1, arg2)) {
return;
}
}

ENV 缓存在ram中还是有必要

[TeemoRZ]

建议用类型文件系统中的INODE ,维护一张表用来映射数据的地址；alios things 有类型的 K - V storage 机制，不知是不是参考你的项目，本想移植alios 但依赖其本身系统太多，不太好移植

[armink]

嗯，这个是一个优化点，你可以先改下试试。

[armink]

hi, @TeemoRZ ，最新的版本新加入了缓存机制，查找、写入效率提升非常明显，你可以试试哈~~

[jamesluo11]

@TeemoRZ 请问这个问题你解决了吗？我也发现这里遍历时特别慢。大约50个env, 需要600ms。我已经用cache feature了。