浅い文解析器と深い文解析器

某資料で速度比較があって，どちらも一番速いものが20文／秒とあったけど，これは単に深い文解析器が速いと言うより，比べている浅い文解析器が遅過ぎるのではないかと思う．係り受け解析ぐらいなら，速いものなら10000文／秒ぐらいは出るでしょう（日本語で transition-based なアルゴリズムで良ければ，三年前の計算機環境で，学部生の演習レベルの実装でも（多分係り受け解析のところだけだけど）7500文／秒とか出てた）．深い文解析にも昔関与していた身からすると，ずいぶん速くなったなとは思うけど，後二桁ぐらいは速くならないと，Web スケールのテキスト処理には使えない（何でもクラウドを使えばいいと言うのはどうかと思う）．前段の処理（品詞タグ付け）より処理速度が三桁も遅ければ，どう見ても明らかなボトルネックでしょう．逆に基礎的な解析アルゴリズムの高速化を研究する人は，前段の処理の2倍ぐらいまでの遅さに止めないと，「速い」という看板を掲げてもデータサイズが効くドメインでは使ってもらえないと思う．
[追記] Dynamic Programming for Linear-time Incremental Parsing を眺めていたら，英語の最速の係り受け解析器は確かに25文／秒 (on a machine with 3.2Ghz CPU) だが，実装が Python なのか．ということで，スクリプト言語で実装した浅い文解析器と，コンパイラ言語で実装した深い文解析器が同じぐらいの速度というが正解らしい．と思ったが，Efficient HPSG Parsing with Supertagging and CFG-filtering 辺りを眺めると，深い文解析器の方も，品詞タグ付けの4倍程度の時間しかかかっていないので，単に充分に最適化していないだけなのかもしれない．
[追記] 手元の係り受け解析器を，形態素解析器 (mecab) ，以前作った文節区切り判定器とパイプで繋いで解析してみた．UTF8 の2007年毎日新聞 (816,273文) を解析するのに，解析精度 89.4% のモデルで，IO その他すべて込みで 36.702秒 (22,241文／秒)，91.8% のモデルで，65.40秒 (12,481文／秒) というところ．cabocha 0.60pre4 だと，863.60秒 (945文／秒; UTF8だからだろうか，こんな遅いはずはないのだが)．JUMAN-6.0/KNP-2.0 だと，66文／秒ぐらい（system/main.c で，614/615 行目をコメントアウトしてタイムアウト時に exit しないようにして解析）．