В рекурсивном анализаторе спуска с обратным отсчетом это плохая идея, чтобы держать все токены в списке? Я читал, что это хороший подход, если у нас нет бесконечного количества токенов, но что, если есть большой файл, а количество токенов велико. Будет ли это иметь большое влияние на производительность?Разбор: держит ли все жетоны в списке плохую идею?
Я бы не стал слишком беспокоиться об этом. Если файл настолько велик, что хранение всех токенов сразу занимает значительную часть памяти, тогда абстрактное синтаксическое дерево также будет занимать слишком много памяти. В более общем плане, скорее всего, вам понадобится примерно представление всего файла в памяти раньше или позже. Однопроходные компиляторы даже не подходят для большинства современных языков, а языки, которые уходят с пути, чтобы включить однопроходный компилятор (например, C), платят за него с худшим опытом разработки.
Кроме того, если предположить, что мы не говорим о/++ модели стиля препроцессора C C, разумных файлов кода меньше мегабайта, а это означает, что даже с космосом неэффективного типа маркеров данных самим вы реально смотрите на не более нескольких десятков мегабайт. Любой более крупный файл является патологическим и проблема людей, пишущих такие большие файлы, а не вашу проблему.
Вам нужно учитывать предполагаемое использование вашего языка - люди не пишут миллиардные программы на линии C, но есть генераторы кода, которые генерируют миллиарды строк кода C из другого более компактного языка. –
@ChrisDodd C - странный пример, потому что компиляция файлов C и C++ разумного размера * часто включает в себя токенизацию 100k + строк кода из '# include'. Кроме того, современные компиляторы C уже не однопроходные, поэтому, если вы набросите на них буквально миллиард строк кода, они буквально будут потреблять гигабайты памяти. – delnan
@ delnan: и если вы ежедневно компилируете миллиардные программы на линии C, это не будет проблемой, потому что вы купили компьютер с десятками ГБ ОЗУ, чтобы сделать это, и ваша кредитная карта почти не заметила. (Я видел миллион строк исходных файлов C [да, машина сгенерирована], но я никогда не вижу ни одной миллиардной строки). –
Я в общем согласен с @Delnan. В любом случае большинство компиляторов работают на машинах с огромным объемом памяти по сравнению с размером скомпилированной программы, поэтому пространство не является проблемой.
Я бы сделал дополнительное наблюдение, что , если вы собираетесь хранить полный АСТ, вы по существу сохраняете список токенов в любом случае, как листья АСТ.
Это указывает на направление: не храните полный список токенов сам по себе. Просто планируйте использовать листья AST как его представление.
FWIW, обычно текстовое представление программы больше, чем список токенов, поэтому, если вы можете полностью загрузить исходный код в ОЗУ, список токенов должен быть сравнительно небольшим. Тем не менее, если код вряд ли подходит в ОЗУ, даже добавление одного байта может привести к взрыву памяти. Но пока это технически может быть проблемой, я бы не сказал, что это редко бывает на практике. Я бы подождал с этим, пока это не станет проблемой. – uliwitness