#CSVの件、with-input-from-portをつかわずに、直接portを引数に渡したら、速くなりました。memory 2G,Celeron(R) M 1.60GHz,Ubuntu 12.04 32bit, ken_all.csvで、
#$ gosh csv/test-csv ken_all.csv
;(time (read-data reader (cadr args)))
; real 8.223
; user 7.470
; sys 0.240
$ gosh csv/test-csv ken_all.csv
;(time (read-data kaizou:reader (cadr args)))
; real 7.333
; user 6.900
; sys 0.270 https://gist.github.com/yamasushi/5712069
#時間の性能はtimeをつかって調べるのですが、空間の性能はどうやればいいのでしょうか？ twitterの会話をちらちらみながらコマンドを打ってみるのですが、どうもよくわからないのです。
#ふむ、案外変わるものですね。これだけ速くなるならportを引き回してもいいかな。with-output-portを使ったのはその方がコードが簡潔になるためですが、1行毎にクロージャ+rewind handlerが作られるのが重いのかも。
#空間プロファイラは欲しいんですがまだ作って無いです。(gc-stat)するとこれまでの総アロケート量が取れるので適宜差分を見ればどのくらいアロケートされたかはわかります。あとgoshに-fcollect-statsをつけて起動すると、終了時にちょっと情報が出ますが、今はまだ大したものはないです。
#s/with-output-port/with-input-from-port/ だた
#ありがとうございます。gc-statを試してみました。 ((:total-heap-size 128815104) (:free-bytes 13176832) (:bytes-since-gc 37375072) (:total-bytes 201361744)) これらのどの数字が重要なのでしょうか？
#どれが重要かはあなたが何を見たいかですが、total-heap-sizeはヒープ(プロセスがOSから確保しているメモリ)の量、free-bytesはその中でまだ使ってないメモリ量、bytes-since-gcは最後のgcから何バイトアロケートしたか、total-bytesがプロセス起動後のアロケートの総量です。頻繁にアロケートするけどすぐゴミになって回収されるプロセスの場合はtotal-bytesがどんどん増えるけどtotal-heap-sizeは頭打ちになる。アロケートしたやつがずっとgcされないで残る場合はtotal-heap-sizeが増えてゆく、みたいな感じですね。
#なるほど。そういう風に読めばいいのですね。(使用メモリだけでいいのかなと素朴に考えていました。)
#Boehm GC はオブジェクトの再配置はしないので、 gosh を起動したら終了するまで total-heap-size が減ることはないと考えていいんですよね
#理屈の上ではmmapしたチャンクの中身が全部ごみとして回収されたらmunmapで返却できるので減ることはありえますが、今ざっとコードをみたところそれはやってない感じ。ただtotal-heap-sizeなどはBoehm GCの返す値をそのまま返してるんで、値の正しい意味はBoehm GCがどうそれを計算してるかに依存します。
#どうもよくわからないのですが、昨日の改造をしたら、確保メモリ量が変わるのですが、これはなぜなのでしょう？ https://gist.github.com/yamasushi/5718069 数字の読み方が悪いのかしらん。 #(gc)しているから同じになるだろうと考えたのですが・・・・
#昨日の改造ってどれですか。with-input-from-portを使わないやつのこと? 具体的に指してもらわないとわからんです。
#with-input-from-portを使うと、1行読む度にクロージャおよびハンドラチェインのアロケートが入るので、それを省略した方が消費メモリが少なくなるのは確かです。あとGCはインクリメンタルに走るのでタイミングによってヒープ量は変わり得ます。
Gauche > Archives > 2013/06/05