3 ms·
Memory leaks due to laziness are not as frequent as the interwebs would tell you. It's not like that this type of code appears in every single program you write
by merijnv 13y ago
Memory leaks due to laziness are not as frequent as the interwebs would tell you. It's not like that this type of code appears in every single program you write.
Memory leaks are notorious mostly due to leaks in lazy code looking very innocent when coming from strict languages. After you get comfortable with laziness the same code (usually) stands out very clearly. And even when it doesn't, these leaks aren't very subtle. GHC has a good profiler for memory usage, so tracking them down is mostly trivial and fixing them once you know what's wrong is not very hard.
- jlouis 13y agoThe 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.