| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Perl: разработка для Web > Оптимизация архитектуры больших CGI скриптов |
| Автор: PerlMaster 3.2.2003, 08:58 |
| Исходные данные Есть большой CGI скрипт следующей структуры: if ($action eq "action1") { # много кода ... &sub1(); ... &sub2(); ... &sub3(); ... } elsif ($action eq "action2") { # много кода ... &sub4(); ... &sub5(); ... &sub6(); ... } elsif ($action eq "action3") { .... Цели: 1) Минимизировать время на компиляцию кода 2) Минимизировать память для хранения откомпилированных модулей 3) Совместимость с mod_perl (желательно) Решение 1: вынести код в модули, затем подгружать их по мере надобности с помощью "require 'actionX.pl'". Скрипт примет следующий вид: if ($action eq "action1") { require "action1.pl"; &action1(); } elsif ($action eq "action2") { require "action2.pl"; &action2(); } elsif ($action eq "action3") { .... Чего мы добились: Оптимизировали время и память Недостатки решения 1: 1) Несовместимость с mod_perl: require при 2-м вызове скрипт не будет импортировать в пространство "main::" имена функций из модулей "actionN.pl" 2) Невозможность использовать use strict Решение 2: вынести код в модули, затем подгружать их по мере надобности с помощью "require Module;" или eval("use Module"). Скрипт примет следующий вид: if ($action eq "action1") { eval("use Action1"); &Action1::action1(); } elsif ($action eq "action2") { eval("use Action2"); &Action2::action2(); } elsif ($action eq "action3") { .... Чего мы добились: 1) Оптимизировали время и память 2) Добились совместимости с mod_perl Недостатки решения 2: 1) Огромные затраты времени на переписывание всего скрипта с учетом новых пространств имен. 2) Более громоздкая запись глобальных переменных и глобальных функций. 3) Невозможность использовать use strict. Есть у кого соображения по усовершенствованию предложенных решений, или же принципиально новые решения ? |
| Автор: Nekto 5.2.2003, 00:35 |
| Я не ослышался? Компиляцию? Тогда батенька пишите на с++, ибо прога после компиляции, написанная на Perl и содержащая один цикл у меня весила более одного метра. Perl - язык интерпретируемый. И не стоит нарушать установившиеся стандарты... Далее, возникнут с мод_перлом, т.к. при изменении модуля - кеш сервяка не выгружается, потому сервер не будет исползовать нормально новую версию модуля. А это значит - все модули должны находится в одном файле... Так что думай, все зависит от конкретной задачи... |
| Автор: Wowa 5.2.2003, 00:51 | ||
хм, насколько я знаю, проблем с кешированием при использовании mod_perl - вообще никогда не возникает. Когда я делал подобные вещи на перл, то я использовал Решение №1. |
| Автор: PerlMaster 5.2.2003, 06:11 |
| 2 Nekto: Да, перл компилирует модуль перед выполнением, если ты не знал (не в машинный код, конечно). В дальнейшем советую не вступать в дискуссии по темам, в которых не разбираешься. Это вредит репутации. 2 Admin: спасибо за информацию. |
| Автор: Unregistered 5.2.2003, 19:03 |
| PerlMaster Вах, вах, вах... Можно спрасить а во что он компили модуль? И что вы понимаете тогда под словом компиляция. Советую вам думать, прежде чем писать. Повторяю вам еще раз. Perl - язык интпретируемый. mod_perl - уже не совсем. Однако не о нем была заведенна речь. А то есл судить - то бейсик - это тоже компилируемый язык  .Впреди внимательней читайте ;) |
| Автор: PerlMaster 6.2.2003, 11:09 |
| 2 Nekto (Unregistered): Читаем очень внимательно: http://www.perl.com/doc/FMTEYEWTK/comp-vs-interp.html Теперь понятно, что слово "compilation" в зависимости от контекста может иметь разные значения? В контексте C++ - это создание последовательности инструкций процессора, а в контексте Perl - это посторение синтаксического дерева. The perl executable you are using has two distinct stages. First comes the frontend, which is certainly a compiler of sorts. It compiles your perl program source into a parse tree. |