| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Perl: Общие вопросы > Разбиение кода на много *.pm |
| Автор: Ramirez 27.5.2005, 23:57 |
| Собственно, вопрос о производительности / логичности разбиения большой программы на кучу модулей. Кроме логичности кода/удобства есть плюсы? Потери в скорости интерпретации будут (пока он там все файлы соберет подключит)? |
| Автор: korob2001 28.5.2005, 00:35 |
| Конечно будут. Только для человека, зачастую, важнее удобство работы с программой чем её производтельность. Если юзать ООП, то будет работать ещё медленей. |
| Автор: Vaneska 28.5.2005, 07:46 |
| То есть получается чем больше вызовов функций, подключения модулей, и других напрямую не связанных с алгоритмом программы действий, тем медленнее программа и более читаемый код. Получается, если производительность действительно критична, надо делать без ООП и с минимумом функций и модулей - чистый алгоритм. Но с читаемостью этого добра действительно проблемы будут. Судя по твоему сучаю (большая прога) наверно лучше будет всетаки разбить на модули, систематизировать код. Потом гораздо проще в нем разбираться и изменять/дополнять по прошествии времени. |
| Автор: korob2001 28.5.2005, 08:56 |
| Лично я, по возможности, стараюсь пользоваться ООП. Почему??? Потому что, когда ты подключаешь класс и создаёшь объект этого класса, ты ничего не грузишь, все методы подгружаются по мере их нужды, т.е. вызовов. Да и код получается более элегантный, плюс не будет конфликта, если у тебя, в текущем пространстве имён текущего пакета, есть функции с такими же именами, как и в подключаемом модуле. У модуля немного другая стратегия, он как правило всегда экспортирует свои функции в текущий пакет main. Производительность при использовании модуля выше, потому как он делает экспорт на стадии компиляции. Потому когда подключаешь какой-нить модуль, всегда нужно стараться использовать его на полную катушку, да бы оправдать его самого. Вот например: часто встречаю код, где люди подключают, не маленький, модуль CGI.pm, при этом в подключении используют экспорт стандартных функций use CGI qw( :standard ), что ещё хуже вижу такое подключение use CGI qw( :all );, а пользуются только функией param() |
| Автор: Ramirez 29.5.2005, 02:05 |
| Спасибо за ответы. В частности, отдельная благодарность тов. korob2001 за его грамотные и содержательные ответы, и вообще за поддержку этого форума, всегда приятно сюда зайти. (давно хотел сказать, да как-то руки не доходили =)). Еще раз - респект. |
| Автор: versus 29.5.2005, 03:01 | ||||
Конечно! Real programmers code in binary!
:-)) |
| Автор: Anarki 29.5.2005, 14:02 |
| korob2001 Так, а вот я использую use CGI qw( :param ); но у меня в коде есть вызовы `start_html()`, `end_html()`,`cookie` однако всё прекрасно работает - Perl делает "дозагрузку" этих частей? |
| Автор: korob2001 29.5.2005, 15:03 | ||||||||||||||
Просто ты наверное юзаешь ООП и соответственно ты можешь обращаться к любому методу, через объект, т.е. скорее всего ты пишешь так:
Это не правильно, потому как ты экспортировал функцию param() в текущий пакет и наверняка юзаешь её так:
Получаются накладные расходы. Вот что происходит: 1. Экспортируется функция param() в тещее пространство имён. 2. Ты создаёшь объект. 3. Вызываешь param() через объект. Вопрос: зачем нужно было экспортировать param(), если ты всё равно пользуешься ООП подходом??? Т.е. шаг 1 абсолюно не нужен. Вобщем, когда юзаешь ООП не нужно вообще ничего экспортировать в текущее пространство имён, ты же обращаешься к методам через объект. Другими словами достаточно написать:
или так:
Попробуй запустить такой код:
И получишь такую ошибку: Undefined subroutine &main::header called at Untitled line 5. А теперь давай исправим ошибки, т.е. экспортируем все нужные функции:
Вот теперь код будет работать на ура. Если хочешь, попробуй удали из списка экспортируемых функций, хотя бы одну из них, например: :end_html И получишь опять сообщение об ошибке. Удачи. |
| Автор: Anarki 8.6.2005, 21:28 | ||
| Ок, спасибо за разъяснения. Я использовал метод объекта
|