Чтение всего файла или отображение в памяти будет быстрее, но может вызвать проблемы, если вы хотите, чтобы ваш язык мог #include других файлов, поскольку они будут отображаться в памяти или считываться в память.
Функции stdio будут работать хорошо, потому что они обычно пытаются буферизовать данные для вас, но они также имеют универсальное назначение, поэтому они также пытаются искать шаблоны использования, которые отличаются от чтения файла от начала до конца, но это не должно не слишком много накладных расходов.
Хорошим балансом является наличие большого кругового буфера (x * 2 * 4096 хорошего размера), который вы загружаете с данными файла, а затем считываете из вашего токенизатора. Всякий раз, когда данные блока передаются вашему токенизатору (и вы знаете, что он не будет сдвинут назад), вы можете пополнить этот блок новыми данными из файла и обновить некоторую информацию о расположении буфера.
Еще одна вещь, которую следует учитывать, - есть ли шанс, что токенизатор когда-нибудь понадобится использовать для чтения из канала или от человека, набирающего текст напрямую. В этих случаях ваши операции чтения могут вернуть меньше данных, чем вы запрашивали, без их нахождения в конце файла, а упомянутый выше метод буферизации становится более сложным. Буферизация stdio хороша для этого, поскольку ее можно легко переключить в / из буферизации строки или блока (или без буферизации).
Использование gnu fast lex (flex, но не Adobe Flash) или аналогичного может значительно облегчить проблему со всем этим. Вы должны использовать его для генерации кода C для вашего токенизатора (лексический анализ).
Что бы вы ни делали, вы должны попытаться сделать это так, чтобы ваш код можно было легко изменить, чтобы использовать другую форму просмотра следующего символа и использовать функции, чтобы, если вы передумали, вам не пришлось начинать все сначала.