fix memory leak
I'm unsure why this fixed it, but it did. Seems to suggest that the memory leak is not due to a bug in my code, but that ghc didn't manage to take full advantage of laziness, or was failing to gc something it could have.
This commit is contained in:
parent
095593a9af
commit
0f4ee4f298
3 changed files with 20 additions and 38 deletions
|
@ -4,28 +4,6 @@ Mostly working!
|
|||
|
||||
Current todo list:
|
||||
|
||||
* copy --to peer of a 100 mb file causes the memory of the remotedaemon
|
||||
to creep up from 40 mb to 136 mb. Once the transfer is done, the
|
||||
remotedaemon continues using all that memory. Memory leak. Profile it.
|
||||
(The sending process creeps up some initially, but stops at 45 mb used.
|
||||
That could just be buffering.)
|
||||
(copy --from peer does not leak on either end; the remotedaemon uses 34
|
||||
mb and the receiver 44 mb.)
|
||||
|
||||
Profiling results: Leak is in hGetMetered, or perhaps in
|
||||
the consumer of the data it reads. Graph shows `ARR_WORDS` is
|
||||
the type; that must be a bytestring.
|
||||
|
||||
<pre> individual inherited
|
||||
COST CENTRE MODULE no. entries %time %alloc %time %alloc
|
||||
tryNonAsync Utility.Exception 3241 0 0.0 0.1 49.3 65.8
|
||||
receiveExactly P2P.IO 3429 0 0.0 0.0 49.3 65.7
|
||||
hGetMetered Utility.Metered 3430 0 49.1 65.6 49.3 65.7
|
||||
</pre>
|
||||
|
||||
Switching to L.hGet, it still leaks, so seems hGetMetered is not at fault
|
||||
and the bytestring is being buffered excessively somehow.
|
||||
|
||||
* When a transfer can't be done because another transfer of the same
|
||||
object is already in progress, the message about this is output by the
|
||||
remotedaemon --debug, but not forwarded to the peer, which shows
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue