次: , 前: Optimization, 上: Optimization


6.1 スピードの最適化

多くのプログラムは、 字句解析の処理に多くの時間を費やします。 したがって、 スキャナの最適化はかなり大きな性能改善に結びつくことが多いのです。 Flexによるスキャナは、 Lexによるスキャナと比較するとかなり高速になる傾向がありますが、 特定の構成もしくはアクションによって、 性能に大きな影響を与えることができます。 注意すべき点は以下のとおりです。

  1. テーブルの圧縮
    どのような圧縮も結果的にスキャナを遅くします。 したがって、 スピードのことが心配であるならば、 常にコマンドラインで`-f'オプション、 または`-F'オプションを使ってください。 テーブルの圧縮とスピードに関連するオプションに関する詳細な議論については、 See Table Compression and Scanner Speed
  2. REJECT
    スピードに対して最も大きな影響を及ぼします。 これが使われるとすべてのマッチ処理が遅くなります。 というのは、 スキャナは、 マッチする前の状態に自身を復旧する必要があるからで、 このようなことが必要ない場合と比較して、 より多くの内部的な保守作業を行わなければならないからです。 スピードが重要な場合には、 使わないようにしてください。
  3. バックトラッキング
    スキャナがあるテキストにマッチするために「逆行」しなければならないことを、 バックトラッキングといいます。 これは、 スキャナの性能に悪い影響を及ぼしますので、 スピードが最も重要である場合には避けるべきです。 圧縮されたテーブルは常にバックトラッキングを発生させるので、 `-f'オプション、 または`-F'オプションを使わない場合は、 ルールからバックトラッキングを削除しようとするのは時間の無駄です。 スキャナからバックトラッキングを削除することに関する詳細な情報については、 See Removing Backtracking
  4. 可変長後続コンテキスト(variable trailing context)
    可変長後続コンテキストとは、 あるルールの先頭部分と後続部分の両方が固定長でないような場合を指します。 性能の観点からはREJECTと同じくらい悪影響を及ぼすもので、 可能な場合にはいつでも避けるべきです。 この例を示すと、 以下のようになります。
              %%
              linux|hurd/(OS|"Operating system")
         

    これは、 以下のように分割すべきです。

              linux/OS|"Operating system"
              hurd/OS|"Operating system"
         

    こうすることによって、 問題は解消されます。

  5. 行の先頭を表す演算子
    `^'演算子は、 性能に不利な影響を及ぼします。 スピードが最も重要な場合には、 使わないでください。
  6. yymore()
    yymoreを使うと性能を低下させます。 スピードが最も重要な場合には、 使わないでください。
  7. テキスト長
    スキャナの性能は、 マッチするテキストの長さによっても影響を受けます。 常に長い文字列にマッチするような場合には、 スキャナは高速に実行されます。 というのは、 yytext環境をセットアップする必要がないからです。 スキャナの実行時間のほとんどは、 内部の高速なマッチング・ループの中で費やされることになります。
  8. NUL
    Flexは、 NULを含むトークンをマッチするのに時間がかかります。 この場合には、 短いテキストにマッチするようルールを記述するほうが良いでしょう。

========================================================================

========================================================================