Open scryclip opened 1 year ago
Can you provide a minimal reproducible example? Maybe use psutil to show memory usage over time.
I tested with the script below (key/no-key,forward/reverse,exhausting/stopping,various lengths,various numbers of iterables) and could not find good evidence of a leak. Since dynamic memory allocation is used, occasionally there is fragmentation that requires allocating new pages, but not in any consistent way: memory usage fluctuates, but is ultimately bounded. It may just be that multimerge.merge
uses more dynamic memory allocation, so there is naturally more fragmentation and slight variations in memory usage over time.
I suppose another possibility is that multimerge.merge is holding onto some references slightly longer that heapq.merge does. For example, I believe the computed key(x)
values might be preserved for one more iteration, which is within the realm of reasonable implementation details.
On the other hand, if you can demonstrate that something is systematically and permanently leaking, that would certainly be a bug worth fixing, but I can't know without a reproducer.
I swapped out heapq.merge for this on a continuously running process. A new call to mulitmerge.merge would be made often it was passed a *list of generators with a key. The instance of the multimerge.merge iterator would not be exhausted it would be used in a loop until a break and just be garbage collected and created anew in a future loop. This would slowly leak memory. Switching back to heapq.merge resolved it. Either something is not deleted In the C or the python gc is not able to fully clean up the multimerge instance when it removes it.