Re:Haskell vs. Erlang for bittorent clients
by jlouis on Saturday January 04, 2014 @09:09AM
(#7011066)
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.
Re:Haskell vs. Erlang for bittorent clients
by Filligree on Saturday January 04, 2014 @10:08AM
(#7011248)
What leak-debugging tools did you use?
Re:Haskell vs. Erlang for bittorent clients
by jlouis on Saturday January 04, 2014 @11:47AM
(#7011671)
GHC 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.
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.