hiroto@hiroto-XPS-13-9360:~/haskell/cardano-diagnosis-program$ stack exec diagnosis "/home/hiroto/Downloads/logs (6).zip" -- +RTS -s
Running analysis on logs
Analysis done successfully!! See result-2018-04-19.html
2,031,484,272 bytes allocated in the heap
791,850,816 bytes copied during GC
189,980,952 bytes maximum residency (12 sample(s))
3,383,016 bytes maximum slop
433 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 1910 colls, 1910 par 3.579s 0.844s 0.0004s 0.1591s
Gen 1 12 colls, 11 par 0.018s 0.004s 0.0004s 0.0012s
Parallel GC work balance: 5.67% (serial 0%, perfect 100%)
TASKS: 18 (1 bound, 17 peak workers (17 total), using -N8)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.000s ( 0.001s elapsed)
MUT time 0.716s ( 0.818s elapsed)
GC time 3.597s ( 0.848s elapsed)
EXIT time 0.000s ( 0.023s elapsed)
Total time 4.313s ( 1.691s elapsed)
Alloc rate 2,839,001,278 bytes per MUT second
Productivity 16.6% of total user, 49.8% of total elapsed
gc_alloc_block_sync: 18951
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 7944
State を使う必要はないように感じます。State Analysis () な型の関数しか見当たらないためです。Analysis -> Analysis な関数にすればよいのではないでしょうか。1. どのようなテストを行えばいいのかわかりません。（ダミーファイルを作ってそれをパースするとか？）詳しく見ないとなんともいえませんが、それが一番要求に近い部分をテストしているっぽいので、いいんじゃないでしょうか？
2. ログを解析する部分(`Classifier.hs`)が総当りに近いです...いい例はぱっと思いつきませんが、とりあえず今の実装でも十分にシンプル（
State Analysis () をやめることでもっとシンプルになりますが）なのでよいのではないでしょうか。とくにユーザー名に半角英数字以外を使用しているユーザーに対して動作するのか
2,030,484,352 bytes allocated in the heap
552,951,344 bytes copied during GC
130,383,808 bytes maximum residency (10 sample(s))
2,306,112 bytes maximum slop
251 MB total memory in use (0 MB lost due to fragmentation)
hiroto@hiroto-XPS-13-9360:~/haskell/cardano-diagnosis-program$ stack exec diagnosis "/home/hiroto/Downloads/logs (6).zip" -- +RTS -s
Running analysis on logs
Analysis done successfully!! See result-2018-04-19.html
2,011,567,408 bytes allocated in the heap
127,421,808 bytes copied during GC
26,902,264 bytes maximum residency (10 sample(s))
432,904 bytes maximum slop
69 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 1893 colls, 1893 par 1.366s 0.185s 0.0001s 0.0090s
Gen 1 10 colls, 9 par 0.011s 0.001s 0.0001s 0.0003s
Parallel GC work balance: 5.20% (serial 0%, perfect 100%)
TASKS: 18 (1 bound, 17 peak workers (17 total), using -N8)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.001s ( 0.001s elapsed)
MUT time 0.742s ( 0.693s elapsed)
GC time 1.376s ( 0.186s elapsed)
EXIT time 0.002s ( 0.011s elapsed)
Total time 2.121s ( 0.891s elapsed)
Alloc rate 2,710,634,667 bytes per MUT second
Productivity 35.1% of total user, 79.0% of total elapsed
gc_alloc_block_sync: 17614
whitehole_spin: 0
gen[0].sync: 3
gen[1].sync: 334
Lazy の代わりに Strict 使っても速度に差はほとんどなかった） とかですね依存関係が面倒なことになっていることとか
速度とかで改善できる点があるのかどうか
stack test --profile するだけでテスト時にプロファイリングまでしてくれるいい時代になりました。StateT s IO a はおすすめしません。例外が発生した際に状態を戻すすべがないからです。ReaderT (IORef s) IO a みたいな型で代用するのをおすすめします。すべてはプロファイリングしてから考えましょう。たしかに。せっかくstack使っているんだから便利に使っていかねばですね
ReaderT (IORef s) IO aの記事は私も目を通していました（「あっこれ直さなきゃ」ってなった）（とはいえ、現状のはデバッグ用のテストコードなので、そもそも全部書き直す可能性のほうが高そう）
UnboxedVector
let! ( let ではなく)に相当するものとして given という関数を用意したのですが、これで定義した値を参照するには refer を使わなければならない、という点が受け入れられるか気になっています。