#GHC で、あるデータの実際のバイト数を調べるには、どうすればいいでしょうか? たとえば、Data.Map の Tip と Bin が 32 ビットマシンで、何バイト占めるか知りたいです。
#Tipが1ワードで、Binは構成子1ワード + unpackされたSize 1ワード + kへのポインタ1ワード + aへのポインタ1ワード + Mapへのポインタ1ワード x 2 = 6ワードに加えて、実際にアロケートされるkとvのサイズを加えたものになると思います。
#1ワードは32ビットマシンなら32ビットです。
###unpackされた値がどうコンパイルされているかは-ddump-prepを付けてコンパイルするとよくわかります。オプションの意味はezyangさんの解説がとてもわかりやすいです。 http://blog.ezyang.com/2011/04/tracing-the-compilation-of-hello-factorial/ #Johan Tibellさんのビデオは9分すぎあたりからちょうど同じような話をホワイトボードで解説しています。
##データの基本的なレイアウトは知っているのですが、手計算ではなく、C の sizeof のように、コンパイラに計算させたいのです。
#なるほど。そういうツールは残念ながら知りません。
#構成子が3つまでだと、ポインターの2ビットを使って、占有するバイト数が少なくなるそうなんですが、-ddump-prep の出力を見ても、そのことは分からないような気がします。
#32ビットアーキテクチャでの話。
#The Masahiro Sakai Daily is out! http://bit.ly/dWV46A ▸ Top stories today via #RWH で、リストのパターンマッチをするとき、(x:xs) を先に書いて、[] を後に書いていますね。ghc -c -ddump-stg してみると、見事に data での定義順にソートされます。リストの場合は、[] が先になります。なので、無意味ですね。
#data で定義する構成子の順で、性能に差が出ることがあるようですね。