Сильно ли теряется производительность и повышается потребление системных ресурсов (таких как память) программы на скриптовом языке при переходе от монолита к модулям

ИМХО зависит от системы в целом, а не только от интерпретатора и иже с ним. Проще замерить время запуска и работы - а ля отпрофилировать и вопросов не будет :)

делайте так, чтобы было проще поддерживать программу - вот Сотлман в своё время обломался, потом писал на всех заборах что tcl отстой :)

правильное решение (imho) разделить проект на библиотеки и бизнес-логику которая их дергает. Пихать кажую процедуру в отдельный файл, не самое лёгкое решение - его потом сложно поддерживать.

вопрос по поводу скорости вызова интрепретатора - вообще непонятен, что имеется в виду ?

Если процедура вызывается из монолита, то она, как я понимаю, интерпретируется текущим интерпретатором. А если из отдельного файла - другим. Я не знаю, как вызывается копия интерпретатора и как замерить ее вызов, отсюда и вопрос о трёх методиках.

>Пихать кажую процедуру в отдельный файл, не самое лёгкое решение - его потом сложно поддерживать.

Будет программа, работающая по такому типу: есть джанные и в зависимости от результатов их анализа вызывается та или иная процедура. Разве не легче будет в этом случае сделать список файлов с процедурой в каждом?

Ты не понимаешь, в смысле, понимаешь неправильно. Единственный "скриптовый язык", который работает подобным образом - это шелл ;)

На питоне и перле разницы в производительности между (одним скриптом) и (скриптом с кучей модулей) никакой (ну, затраты на open N раз можно не учитывать). На тыцыле - не знаю, но не думаю, что что-то отличается.

Опять жешь, если тебе нужен dispatch table, то и в питоне, и в перле, и в тыцыле функции - first class objects, и их можно смело хранить в (ассоциативных) массивах. Т.е. вместо

if (data_type == smth ) process_smth(data)

else if (data_type == smth_else ) process_smth_else(data)

можно написать

lookup_table[data_type](data)