AdaでCGIを書かないべき10の理由
なんちゅーかレスポンス遅いにゃーと思うんじゃー。えいだがわるいのか！この約180歳め！ 口に出すのも憚られる人の村
……というわけでいつもと逆のことをほざきます。
ネィティブ言語なので起動が低速。
ぶっちゃけmodなんちゃらの方が速いです。
AdaのgenericはC++のtemplateと異なり同じ型で実体化しても実装が共有されない。
実行ファイルサイズが大きくなるとますますmodなんちゃらに差を付けられることに。
細かい演算ひとつひとつに実行時チェックが行われる。
実行時チェックOFFでコンパイルしたものをアップロードする勇気が無いだけです。デバッグの助けとしては大変ありがたいんですが、速度となりますと、ね。
効率のいい文字列操作ができない。
やっぱ組み込みの可変長文字列がないと話にならんですよ。
GCが無い。
CGIのように一瞬で終了するタイプはどうしてもまとめて解放が有利です。そもそも解放しない、という対抗策がありますが、実行する勇気が無いですごめんなさい。
環境ごとにlibc.aはあってもlibada.aなんてものは無い。
GNATのRTLは間接的にlibcを用います。レイヤーが一枚多い分遅いです。特にlibcのstdioのバイナリ/テキストのモードは余計なお世話でこのためにGNATのRTLは出力内容を全部走査したり。
そもそもGNATはそんなに頭のいいコンパイラではない。
String'WriteなんかAda.Streams.Write一発でいい筈なのにループしますよ奥さん。
gccバックエンドはそれほどAdaのことを考えられているわけではない。
以下略。
そもそも私が以下略
たとえばさいしゅうてきにえいちてぃーえむえるをだすときはこだしにするのとめもりじょうでつくりあげてからいっきにはくのとどっちがいいのでありませうか。わかりません。おしえてせんせいさん。
gprofの使い方が良くわかりません。
廊下で立ってなさい。
最近はこの手のネタしか書いてないような気がしてきた
しかもほとんどパクリですorz
とりあえずAda.Containers.Vectorsを配列に書き戻し中。速度は知りませんが実行ファイルサイズは減りました。Cursor(イテレータのようなもの)なんかで気取ってもいいこと無いと気付きました。レジスタサイズに収まる整数インデックスこそこの道我が道ですよ。つーかAdaは至急operator()をサポートするべきだと思います。
つーか言語云々よりも、データ形式がYAMLってのが元凶のような。気付かなかったことにする。*1
それはそれとして、なんか錚々たるIdが並んでいるような……;;;;
