isli的生成器环路中可能存在内存泄漏

Question

我正在处理一个大文件，每个文件包含几百万条记录（大约2GB未打包，几百MbsGZIP）。在

我用islice遍历记录，这允许我在测试代码时获得一小部分（用于调试和开发）或全部内容。我注意到我的代码内存使用量非常大，因此我试图在代码中查找内存泄漏。在

下面是memory_profiler在成对读取（打开两个文件并压缩记录）时的输出，结果只有10**5个值（默认值被覆盖）。在

Line #    Mem usage    Increment   Line Contents
================================================
   137   27.488 MiB    0.000 MiB   @profile
   138                             def paired_read(read1, read2, nbrofitems = 10**8):
   139                              """ Procedure for reading both sequences and stitching them together """
   140   27.488 MiB    0.000 MiB    seqFreqs = Counter()
   141   27.488 MiB    0.000 MiB    linker_str = "~"
   142                              #for rec1, rec2 in izip(read1, read2):
   143 3013.402 MiB 2985.914 MiB    for rec1, rec2 in islice(izip(read1, read2), nbrofitems):
   144 3013.398 MiB   -0.004 MiB        rec1 = rec1[9:]                         # Trim the primer variable sequence
   145 3013.398 MiB    0.000 MiB        rec2 = rec2[:150].reverse_complement()  # Trim the low quality half of the 3' read AND take rev complement
   146                                  #aaSeq = Seq.translate(rec1 + rec2)
   147                             
   148                                  global nseqs 
   149 3013.398 MiB    0.000 MiB        nseqs += 1
   150                             
   151 3013.402 MiB    0.004 MiB        if filter_seq(rec1, direction=5) and filter_seq(rec2, direction=3):
   152 3013.395 MiB   -0.008 MiB            aakey = str(Seq.translate(rec1)) + linker_str + str(Seq.translate(rec2))
   153 3013.395 MiB    0.000 MiB            seqFreqs.update({ aakey : 1 })  
   154                                  
   155 3013.402 MiB    0.008 MiB    print "========================================"
   156 3013.402 MiB    0.000 MiB    print "# of total sequences: %d" % nseqs
   157 3013.402 MiB    0.000 MiB    print "# of filtered sequences: %d" % sum(seqFreqs.values())
   158 3013.461 MiB    0.059 MiB    print "# of repeated occurances: %d" % (sum(seqFreqs.values()) - len(list(seqFreqs)))
   159 3013.461 MiB    0.000 MiB    print "# of low-score sequences (<20): %d" % lowQSeq
   160 3013.461 MiB    0.000 MiB    print "# of sequences with stop codon: %d" % starSeqs
   161 3013.461 MiB    0.000 MiB    print "========================================"
   162 3013.504 MiB    0.043 MiB    pprint(seqFreqs.most_common(100), width = 240)

简而言之，代码对记录进行一些过滤，并跟踪字符串在文件中出现的次数（在这种情况下是压缩的字符串对）。在

在一个计数器中，包含150个字符的100000个字符串的最大值应该是100mbs，我使用下面的函数通过@AaronHall检查了这个值。在

考虑到memory_profiler的输出，我怀疑islice不会在迭代过程中放弃前面的实体。一个google搜索让我在this bug report上找到了，但是它被标记为python2.7解决了，这正是我目前正在运行的。在

有什么意见吗？在

编辑：根据下面的注释，我尝试跳过islice，并使用类似for循环的

^{pr2}$

这没什么大不了的。在单个文件的情况下，为了避免izip，它也来自{}。在

我的第二个故障排除方法是检查gzip.open()是否读取并将文件扩展到内存中，从而导致这里的问题。不过，在解压文件上运行脚本并没有什么不同。在

Answer 1

请注意，memory_profiler只报告每行的最大内存消耗。对于长循环，这可能是误导，因为循环的第一行似乎总是报告不成比例的内存量。在

这是因为它将循环的第一行与之前该行的内存消耗进行比较，这将超出循环。这并不意味着循环的第一行消耗2985Mb，而是循环内内存峰值之间的差异比循环外高2985Mb。在