これは特に高価なオプションです。ひどく苦労して複雑なスキャナを作ることになります。ファイルを生成することから始めます。ルールにマッチしようとした時です。マッチするルールを探すためのバックアップが必要となります。見た時にある状態に違いないことが分かるでしょう。戻り(バックアップし)ます。スキャンされた時に問題があることを表しています。受理するところまで戻ります。続かない場合に関係します。バックアップを取り除こうと努力することは無意味であることです。性能上の利益は無いからです。TOK_ID;通常、適切な時にはこれは一番良い解決策です。バックアップメッセージはカスケードすることが多いです。複雑なルールの組では、数百ものメッセージを得るのは普通のことです。(しかし、間違えることが多く、誤ったルールが偶然有効なトークンにマッチし得ます。自動的にバックアップを除去するルールを追加するようになるかも知れません)。バックアップを除去した時だけということを覚えておくことは重要です。一つを残しても何も得ることが出来ません。同じだけの(すなわち相当の)性能劣化となります。(後述の欠陥/バグを参照)。マッチするトークンが長ければスキャナが高速になることにあります。ほとんどしないからです。可能な限り長いテキストにマッチするようになっています。(この節の始めで扱いました)とも独立です。識別子とキーワードを全てファイルからスキャンすることを考えます。気を付けなければなりません。バックアップが必要であると考えます。ルールだけがあります。得られるほぼ最速になります。含む時には特に遅いです。部分とマッチするようにルールを書くべきです。サイズを動的に変更すると処理が遅くなります。(巨大な)トークンを再度先頭からスキャンしなおさねばならないからです。