关于读写文件执行速度

[Virace]

代码不好贴, 因为涉及到很多个文件

简单就是:
读取 A 类 文件, 根据偏移量提取出 B 类文件, 解析 B 类文件中的数据.

A 类文件中有可能有多个 B 类文件.
A 类文件几十兆, B 类文件几兆.
B 类文件是不写入本地的, 直接解析.



大概有接近 1000 个 A 类文件, 随着循环时间越来越长, 解析 B 类文件数据的这个函数执行会越来越慢.
多数使用过的变量 都有手动用 del 删除


每次循环 A 文件前 关闭 gc, A 文件使用后开启 gc 手动调用 gc.collect()

随着循环次数变多, 解析 B 类文件的函数, 就会从最开始的几十毫秒到后来的几秒甚至时间更长.

占用内存波动不大, 一直是 300M 左右

[gBurnX]

watch -n 1 'free -h'
htop -d 1
dstat -t -n -d -c -g -i -l -m -p -s -y --ipc --lock --raw --tcp --udp --unix
iostat -x -m -d 1

注意一下函数执行速度，与 内存使用率 / 磁盘活动时间的关系。

[clino]

从 obj_find_one 的实现来看，应该是这个遍历耗时很长，看能否调整数据结构，让这个查询不需要遍历，或者看能否做预处理形成一个中间数据结构让查询不需要遍历。

gc.collect 的优化看看能不能不要每次都做,还有 gc.collect 的参数你看能不能给 0 试试 gc 效果如何。

[Virace]

@clino 去掉这个函数了, 改用字典了, 时间缩短不少. 但开始运行和运行一段时间后性能还是有差别. 目前从 profiler 工具给的信息看, 大部分时间除了几个循环就是 GC 了.

[clino]

gc.collect 的参数调整没用吗？
另外不做 gc 的后果是什么？内存暴涨？能否重用 dict 之类的对象来减少新对象的创建？还有就是检测一下内存用量，超过临界值了再执行 gc 。

[Virace]

@clino 同等情况下手动执行 gc 和自动 gc 占用内存是有区别的, 比如 100 个 A 类文件循环处理时不调用 GC 可能最高内存会超过 1G, 手动调用最高也只在 400M 左右. 但是不管手动调用还是自动, 这个 gc 在整个程序执行时间时间里是得占用个 30 左右. 好多情况得需要额外复制对象在进行处理, 因为原对象后续还需要使用.

[clino]

或者你实在优化有问题，考虑把对象内的数据外包给 redis 处理，这样 python 这里只要做数据查询就可以了，不用面临这种 python 内部内存暴涨的情况