我有段代码，逻辑总结起来比较简单：

@functools.cache
def a_long_time_calc(cis):
    ...

for n in (...):
    cis = tuple(some_dic.keys())
    # cis 有较不小概率是会重复的
    calc_res = a_long_time_calc(cis)
    another_long_time_proc(...)
    ...


因为for n 循环跑的次数比较多， 而且cis本身也不短，导致随程序运行，内存占用会越来越多，然后被系统杀死，用memory_profiler做prof看的结果就是cis = tuple(...)这里不停的占用内存，要命的地方是， some_dic是从数据库里根据n实时抓出来的，他的keys没有办法做成预定义的。在运行一段时间之后主动调用gc.collect也没有效果。
请教一下， 有没有办法在运行一段时间之后把cis这个内存释放掉啊。
    
--
FROM 221.224.37.*

我换了个2T内存的机器把程序完整跑了一遍prof，  memory在cis = tuple(...)那边增加比较多，其他地方微乎其微。


【 在 kawolu 的大作中提到: 】
: 估计是有内存泄漏，只不过最后刚好在那里爆掉
:
--
FROM 221.224.37.*

生成器没法cache, a_long_time_calc非常耗时
【 在 annals 的大作中提到: 】
: 逻辑允许的话,用生成器呗
:
--
FROM 221.224.37.*

改用@functools.lru_cache试试
至少可以设一下maxsize


【 在 pcal 的大作中提到: 】
: 我有段代码，逻辑总结起来比较简单：
: @functools.cache
: def a_long_time_calc(cis):
: ...................
--
FROM 123.123.203.*

some_dic是个不随外部for循环变化的静态字典么？是的话没有必要每次都生成一个tuple？不是的话，每次some_dic的key都不一样，functools.cache作用大么？

如果因为某些原因，some_dic在每次循环中都会变，而且不需要对keys排序，而且functools.cache的命中率还非常高，可以考虑用外部缓存，比如文件系统，sqlite等。但是这些“而且”都成立的情形很奇怪啊。。。


【 在 pcal 的大作中提到: 】
: 我有段代码，逻辑总结起来比较简单：
: @functools.cache
: def a_long_time_calc(cis):
: ...................
--
FROM 111.196.23.*