GHC/Memory Management - HaskellWiki
Haskell computations produce a lot of memory garbage - much more than conventional imperative languages. It's because data are immutable so the only way to store every next operation's result is to create new values. In particular, every iteration of a recursive computation creates a new value. But GHC is able to efficiently manage garbage collection, so it's not uncommon to produce 1gb of data pe
遅延I/Oとメモリリーク - maoeのブログ
先週の土曜日にReal World Haskell読書会に行ってきた。とても有意義な読書会だったのだけど、遅延I/Oとメモリリークに関して腑に落ちない点があったので書いてみる。 遅延I/Oの例 Real World Haskell 7.4.1節の注意マークのところ、邦訳版から引用すると、 上の例で、inpStrを使った一箇所（つまりprocessDataを呼んだところ）を過ぎてから、inpStrを捕まえようとすると、プログラムのメモリ効率が失われてしまいます。 という部分が気になっている。 本を持っていない方のために、わかりやすいサンプルプログラムを例に挙げる。Haskellではテキストファイルを読んでそのまま出力するプログラムをこう書くことができる。 ここで注目すべき点は、BS.readFileは遅延I/Oとなっているので、実際に読むファイルがメモリに載らない大きなものであったとしても、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
System.Mem
http://blog.ezyang.com/2014/05/the-cost-of-weak-pointers-and-finalizers-in-ghc/
