タグ

left-fold enumeratorに関するnsyeeのブックマーク (4)

  • 遅延I/Oとメモリリークのつづき - maoeのブログ

    id:maoe:20091108:1257701870の件をhaskell-ja(chaton)で相談してみたところ、nwnさんとnobsunさんに教えていただきました。ありがとうございました。 せっかくなので、こちらにもまとめを書いておきます。 先のエントリで意図していた例 元々意図していたことは、putStrを2回するなんて恣意的なものではなく、 ログファイルの解析をするとき、1ファイル(あるいは生のログストリーム)から複数種類の解析を行いたい場合 頻出IPアドレスの提示とページビューの計算とユニークユーザ数の計算などを同時にしたい 遅延I/Oとメモリリーク - maoeのブログ というシチュエーションを想定していた。これに対して、スレッドを使うとか姑息な手段ではなく、かつ関数プログラミング的に美しい方法を教えてもらった。 解決策: 関数を融合してfoldl 上記の例では 頻出IPアド

    遅延I/Oとメモリリークのつづき - maoeのブログ
  • 遅延I/Oとメモリリーク - maoeのブログ

    先週の土曜日にReal World Haskell読書会に行ってきた。とても有意義な読書会だったのだけど、遅延I/Oとメモリリークに関して腑に落ちない点があったので書いてみる。 遅延I/Oの例 Real World Haskell 7.4.1節の注意マークのところ、邦訳版から引用すると、 上の例で、inpStrを使った一箇所(つまりprocessDataを呼んだところ)を過ぎてから、inpStrを捕まえようとすると、プログラムのメモリ効率が失われてしまいます。 という部分が気になっている。 を持っていない方のために、わかりやすいサンプルプログラムを例に挙げる。Haskellではテキストファイルを読んでそのまま出力するプログラムをこう書くことができる。 ここで注目すべき点は、BS.readFileは遅延I/Oとなっているので、実際に読むファイルがメモリに載らない大きなものであったとしても、

    遅延I/Oとメモリリーク - maoeのブログ
  • Streams and Incremental Processing

    Stream processing defines a pipeline of operators that transform, combine, or reduce (even to a single scalar) large amounts of data. Characteristically, data is accessed strictly linearly rather than randomly and repeatedly -- and processed uniformly. The upside of the limited expressiveness is the opportunity to process large amount of data efficiently, in constant and small space. Introduction

  • Google Sites: Sign-in

  • 1