3 ms·
The memory leaks I had to work around in combinatorrent were extremely subtle: loop = forever x and loop = do {x; loop} had different laziness semantics in the
by jlouis 13y ago
The memory leaks I had to work around in combinatorrent were extremely subtle:
loop = forever x and loop = do {x; loop} had different laziness semantics in the Process monad. The former leaked, the latter did not.
I wrote all of the code in about 1.5 months, but spent the next 2-3 months fighting with memory leaks. In typical batch-processing code this is hardly a problem since a small leak goes away once the program terminates. In a long-running daemon-process, this is not as easy.
- Filligree 13y agoWhat leak-debugging tools did you use?
- jlouis 13y agoGHC has a very nice memory profiler in the runtime. You just enable that one and then it has rules to constrain views of allocation data. Profiling by "anything of type X" usually helps to narrow down a specific place in the code which has trouble. Also, splitting by module helps since it can tell you where in the code base you have the leak. It won't point and scream HERE!, but it will give you enough information that you can use to narrow down where the leak happens to be.