fbc пытается избежать лишних выделений памяти , так как это довольно медленная операция. Связанный список, реализованный в list.bas, идет со встроенным пулом памяти, таким образом, в значительной степени каждый список объединен. Пул памяти предварительно выделяет большие блоки и может тогда быстро раздать много маленьких узлов. Эти списки обычно используются для простых вещей, таких как список библиотек, ссылки на исполняемый файл, но иногда и для более тяжелых вещей, как АСТ узлы. Пул памяти по идее должен ускорять этот процесс (но в реале не было необходимости это проверять).

Во многих местах компилятор просто использует глобальные/статические переменные, например строки фиксированной длины, во избежание выделений памяти. Маркеры - хороший пример: lex.bas анализирует входные символы в маркеры и хранит символический текст в статических буферах. Символический текст, который может быть: именем переменной, строковым литералом, и т.д. Все маркеры сохраняются здесь, таким образом, препроцессор может правильно записать макросы. Теперь примите во внимание огромное число маркеров, с которыми должен иметь дело парсер: Например, текущие заголовки Windows FB приводят к ~100k маркерам. Динамичное выделение буфера для каждого маркера очень быстро стало бы неэффективным.

Конечно длина маркера ограничена при помощи статического буфера, но значение fbc по умолчанию 1024 байт должно быть достаточно для всего. Подобные ограничения длины применяются ко многим вещам в компиляторе из-за использования буферов фиксированной длины. В большинстве ситуаций буферы в компиляторе не привыкли к их полному потенциалу, т.е. они больше, чем они должны быть.

Все это не означает, что компилятор не использует динамического распределения памяти вообще. Это делается в ситуациях, когда выделение проще, чем использование списка/пула и скорость не критична. Встроенные строковые типы FB также используются во многих местах . Покуда строки хранятся выделенными, они очень эффективны. Расширение макро-параметра stringifying в препроцессоре использует strReplace() на основе строки, и это достаточно быстро. Помимо этого, динамические строки, которые являются в основном такой же строкой, используются везде в препроцессоре от записи макроса до макрорасширения.

Out-of-memory (выход за рамки памяти) шибко не обрабатываются. Есть нулевые проверки некоторых мест, где вызываются allocate() , но эти проверки бессмысленны, так как остальная часть fbc на нулевые проверки не проверяется. Нулевая проверка иногда используется, чтобы указать ошибку, например с некоторыми функциями astNew* () . Кроме того, компилятор не освобождает память (не вызывает deallocate()) для всего, а просто позволяет операционной системе делать очистку.