Ибо бегать по токенам в разы быстрее, чем по тексту. ибо токенов меньше в разы

А для определения токена редко нужно просматривать данные назад или вперёд

Суть в оптимизации по performance не сократить колличество циклов, а уменьшить работу. В вашем случае вы по большей части переместили работу, но не сильно её уменьшили

Я сразу предупрежу, что не очень в этом разбираюсь, но:

> зачем нужен лексер?

И

> Почему бы сразу не парсить текст в базовое промежуточное представление, минуя AST?

Не связаны друг с другом, нет? Lexer занимается преобразованием в поток токенов, а не построением AST.
Т.е. какой у Вас именно вопрос?

да, у меня вопрос зачем поток токенов если можно сразу текст парсить в IR

Поток токеноы быстрее обрабатывать, чем текст

но его нужно тоже обрабатывать чтобы сформировать поток токенов. то есть выполняется больше работы. если у вас есть какие-то бенчмарки которые показывают что с лексером быстрее чем без него, я буду рад посмотреть.

Можно даже на глаз увидеть, что этап парсинга просто слёзки по сравнению с остальными фазами компиляции

мне тут доказывали ровно обратное :)

Создать токены - просто пройти по списку без возвращений назад.
Понять какие конструкции используются - куча логики со вложенными конструкциями, look ahead и прочее. Делать это на тексте, вместо токенов (а это сжатие в 5-6 раз объем данных) просто ну гораздо дольше)

есть бенчмарки?

А у вас, что ваш вариант быстрее?)

я пришел не доказывать что-то а спрашивать.

Вам тоже объясняют)
Бенчи писать за вас никто не будет)

Иногда достаточно представить

Так есть методы lexerless parsing, если что.
И поток токенов почти никогда в явном виде всё равно не строится (разве что при отладке lexer).

По идее, с токенами удобнее работать, потому что:
1. Parsing разделяется на эти модули (lexer и parser), в которых традиционно применяются разные методы описания и обработки (чаще всего regexp-ы в lexer и CFG в parser, по идее).
2. Разработка грамматики, где не нужно учитывать комментарии, переводы строк и т.п., с чем может "разобраться" lexer, может быть проще.
3. Иногда в lexer, наоборот, можно специально распознавать "сложные" конструкции, чтобы упростить работу parser.
4. При таком разделении можно использовать существующие генераторы lexers и parser, чтобы ускорить их разработку.

Тот два вопроса: 1. зачем нужен поток токенов и 2. зачем нужно AST
По поводу 1: грамматика у лексера обычно регулярная и поэтому её можно разбирать более простыми алгоритмами, чем грамматику парсера. Время и там и там O(N), но у парсера константа больше.
Бенчмарков у меня нет.

И от перемещения этих алгоритмов в парсер ничего не ускорится

Ибо понимать что где-то идентификатор, а где-то ключевое слово, а где-то ещё что-то все равно придется

Это только очень простые и ограниченные парсеры работают за O(N)... По факту даже лексер не каждый линейно работает.