Штраф на запуск автономної програми десь на порядок знижує продуктивність у порівнянні з модульною формою роботи інтерпретатора. Ціна запуску інтерпретатора зіграє велику роль, якщо перевага буде надаватись обслуговуванню "швидких" трансакцій в сукупності із незначними обчисленнями, а не повільних із значним процентом обробки. Результатом того, що більша частина часу витрачається на запуск інтерпретатора, а не на виконання сценарію, буде безкорисна витрата ресурсів.

Автономна версія інтерпретатора має тільки одну перевагу над модульним варіантом: її можна налаштувати для роботи під різними ідентифікаторами користувачів. Модульні версії працюють завжди під тим же користувачем, що і Web-сервер, який з метою безпеки завжди має мінімальні привілеї. Це викликає деякі труднощі для сценаріїв яким необхідно спеціальні привілеї (наприклад, якщо необхідно надати право на зчитування файлів, які захищені від запису). При необхідності можна суміщати автономний і модульний підхід. По замовчуванню користуйтесь модульною версією, а автономні використовуйте у випадку, коли сценарію необхідно надати деякі права.

Час розробки програм. Всі описані вище фактори впливають на продуктивність програм. Але просто ефективність виконання програм не може бути єдиною метою. Час розробника також є суттєвим фактором, тому простота програмування також повинна братись до уваги. Створення програми на мові Perl може зайняти вдвоє менше часу, ніж створення аналогічної програми на мові програмування С. Тому перевагу можна надати Perl DBI API, а не С АРІ, навіть беручи до уваги те, що програма буде працювати повільніше. Для програм, які будуть запускатись не так часто, перевага за звичай віддається тому інструментарію, який дозволяє розробляти програми в короткі терміни. Година часу розробника зараз коштує значно дорожче ніж година машинного часу!

В загальному випадку, мови для написання сценаріїв дозволяють написати роботоздатну програму швидше. Особливо це добре при створенні макетів майбутніх програм. Тут грає свою роль щонайменше два фактори.

По-перше, мови написання сценаріїв мають тенденцію до конструкцій більш високого рівня. Це дозволяє розробнику мислити на більш високому рівні абстракції, коли людина думає про те, що треба зробити, у не про те, яким чином цього добитись.

По-друге, цикл розробки програм за допомогою мови написання сценаріїв можна розділити на декілька етапів. Мова С пропонує звичайний цикл "редагування – компіляція – тестування". Після кожного внесення змін у текст програми, вона знову перекомпільовується і тільки після того тестується. Розробка програмного забезпечення за допомогою мов Perl i PHP пропонує спрощений цикл "редагування - тестування", тому що запуск сценарію можливий зразу ж після редагування без всякої компіляції. Однак компілятор накладає багато обмежень на програми у вигляді строгої перевірки типів. Дисциплінуючий вплив компілятора дозволяє запобігти тривіальних помилок, яких буває важко запобігти в мовах Perl i PHP. Компілятор С (як і будь-який інший компілятор) обов’язково попередить розробника про наявність помилки в імені змінної. Мова РНР такого попередження не зробить, а Perl зробить, але тільки якщо розробник попросить про це. По мірі збільшення об’єму розроблюваної програми буде зростати і вага цих обмежень.

В цілому, це традиційна проблема вибору між компільованими і інтерпретуючими мовами програмування, яка полягає у виборі між собівартістю розробки і продуктивністю.

Розглянуті мови програмування розрізняються рівнем своєї безпеки. Інтерфейс С АРІ забезпечує інтерфейс із сервером на самому нижчому рівні і має слабкий захист. В цьому смислі інтерфейс С АРІ забезпечує самий низький рівень захисту. Механізми мов Perl i PHP мають більш високий рівень захисту. Саме страшне, що може відбутися при помилкових діях, - це збій сценарію, але краху інтерпретатора не буде. Ще одним джерелом помилок в С можна назвати динамічний розподіл пам’яті і вказівників зв’язаних з ними. Мови Perl i PHP самі здійснюють управління пам’яттю, і ймовірність їх краху в результаті помилок, викликаних управлінням пам’яттю значно менша.

Час розробки програми на будь-якій мові програмування залежить від об’єму зовнішньої підтримки, доступної для цієї мови. Зовнішня підтримка для мови програмування С доступна у вигляді бібліотек, які мають функції інтерфейсу С АРІ СУБД MySQL у вигляді підпрограм, які простіше використовувати. Такі бібліотеки є як для С так і для С++. Без сумніву, Perl має велике число доповнень у вигляді Perl-модулів (аналогічно концепції модульності Web-сервера Apache). Існує спеціальна інфраструктура, призначена для спрощення пошуку цих модулів (CPAN або Comprehensive Perl Archive Network – повна мережа архівів мови Perl). За допомогою модулів Perl можна дістати доступ до будь-якого типу функцій, не написавши при цьому жодного рядка коду.

Для мови РНР одним із самих популярних доповнень є PHP Base Library (PHPLIB), а також PEAR. Слід зауважити, що починаючи з версії РНР 4, підтримка СУБД MySQL вбудована прямо в ядро РНР. Не потрібно використовувати відповідну зовнішню бібліотеку. Починаючи із 1998 року, мовою РНР опікується фірма Zend Technologies, яка була створена самими ж розробниками РНР. У четверту версію інтерпретатора включені засоби Zend Scripting Engine, що дозволяє збільшити продуктивність роботи сценаріїв у порівнянні з РНР 3 в 2-3 і більше разів. Також починаючи із РНР 4, в ядро інтерпретатора включена бібліотека підтримки сеансів, що є дуже важливою для написання різного роду систем електронної комерції і звичайно, систем, які потребують контролю роботи клієнтів із системою, якою є і дана система. Механізм управління сеансами дозволяє повністю розділити користувачів, які в один і той же момент часу працюють