YaBB — форум из XX века. Смотреть что такое "крайность" в других словарях

КРАЙНОСТЬ

КРАЙНОСТЬ

1. Крайняя степень чего-н., чрезмерное проявление чего-н. От одной крайности к другой бросаться, переходить (о явной непоследовательности в решениях, поступках; неод.). В характере сочетаются две крайности. Крайности сходятся (о людях разных характеров).

2. Тяжёлое, трудное положение, нужда. Дойти до последней крайности. В крайности кто-н.

Толковый словарь Ожегова . С.И. Ожегов, Н.Ю. Шведова. 1949-1992 .

Синонимы :

Смотреть что такое "КРАЙНОСТЬ" в других словарях:

См. нужда впасть в крайность, довести до крайности, до крайности... Словарь русских синонимов и сходных по смыслу выражений. под. ред. Н. Абрамова, М.: Русские словари, 1999. крайность перехлест, предельность, перегиб, экстремальность, нужда,… … Словарь синонимов

КРАЙНОСТЬ, крайности, жен. 1. То, что представляет собою крайнюю степень чего нибудь (мнения, поведения, свойства). Впадать в крайность. Защищаться до последней крайности. Крайности в убеждениях. 2. Крайность, противоположная другой. Переходить… … Толковый словарь Ушакова

крайность - — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN emergency … Справочник технического переводчика

Сущ., ж., употр. сравн. часто Морфология: (нет) чего? крайности, чему? крайности, (вижу) что? крайность, чем? крайностью, о чём? о крайности; мн. что? крайности, (нет) чего? крайностей, чему? крайностям, (вижу) что? крайности, чем? крайностями, о … Толковый словарь Дмитриева

См. Обстоятельства, уменьшающие вину и Наказание … Энциклопедический словарь Ф.А. Брокгауза и И.А. Ефрона

Ж. отвлеч. сущ. по прил. крайний II Толковый словарь Ефремовой. Т. Ф. Ефремова. 2000 … Современный толковый словарь русского языка Ефремовой

Крайность, крайности, крайности, крайностей, крайности, крайностям, крайность, крайности, крайностью, крайностями, крайности, крайностях (Источник: «Полная акцентуированная парадигма по А. А. Зализняку») … Формы слов

крайность - кр айность, и … Русский орфографический словарь

крайность - (3 ж), Р., Д., Пр. кра/йности; мн. кра/йности, Р. кра/йностей … Орфографический словарь русского языка

И; ж. 1. Крайняя степень чего л., чрезмерное проявление чего л. Избегать крайностей при решении важных вопросов. Впадать в к. Это уже к.! Доводить до крайности кого л. (выводить кого л. из себя). 2. То, что совершенно несходно с другим,… … Энциклопедический словарь

Книги

• Супердиджеи: Триумф, крайность и пустота , Дом Филлипс. Книга Супердиджеи: Триумф, крайность и пустота рассказывает честную и неприкрытую историю о том, как…

Бесплатный движок форума на Perl, первая версия которого вышла в самом конце XX века, 4 июля 2000 года. Да-да, XXI век, вопреки распространенному заблуждению, начался лишь с 1 января 2001 года.

На машине времени мы перенесемся в 2000 год и посмотрим, как все начиналось.

→ Демо-версия самого первого YaBB (логин: admin, пароль: admin).

Немного истории

Некий Zef Hemel в начале 2000 года хотел создать свой форум и искал подходящий движок. Лучшим из того, что он нашел, были платные UBB (Ultimate Bulletin Board) за $200 и vBulletin, а также бесплатные UltraBoard 1.62 и PowerBoard. Однако эти форумы табличные, а Zef хотел древовидный в стиле «Usenet» с блекджеком и смайликами.

В итоге Zef Hemel выбрал бесплатный UltraBoard и некоторое время его использовал. Однако со временем ему стало не хватать его возможностей, но он не смог найти форум с необходимым ему функционалом. Zef принимает решение создать свой движок форума.

Поскольку Zef Hemel изначально хотел иметь древовидный форум, он начал модифицировать уже существующий движок RobBoard. Работая над форумом, к нему пришло прозрение: древовидные форумы теряют популярность и морально устарели, поскольку нажимать на каждое сообщение, чтобы прочитать его - это очень неудобно. Таким образом, он отказался от идеи создать древовидный форум и переписал его в табличный, каким он и остается до сих пор.

Изначально он хотел сделать движок платным, но затем изменил свою позицию. Он решил сделать бесплатный форум с открытым исходным кодом для таких же бедных вебмастеров, как он сам. Первая версия форумного движка была выпущена 4 июля 2000 года, в День независимости США. Свой движок он назвал YaBB - Yet another Bulletin Board. В переводе с английского это означает «Еще одна Доска Объявлений».

Вскоре к проекту присоединились еще несколько программистов: Andy Tomaka (специалист по UBB), Remake (специалист по UltraBoard), Matt Mecham (создатель Ikonboard, позже стал руководителем Invision Power Services). Zef опубликовал свой скрипт в различных каталогах CGI-программ, в том числе в CGI-Resource Index.

Новый движок набирал популярность, его начали использовать сайты с высокой посещаемостью. Форум постоянно модернизировался, за несколько лет был выпущен целый ряд новых версий - YaBB 1 Final, YaBB 1 Gold и т.д. Zef Hemel со временем покинул проект, его эстафету приняли новые энтузиасты. Было выпущено огромное количество разнообразных модификаций, собранных на сайте BoardMod .

На смену пришел YaBB 2. Первая публичная версия в статусе Release Candidate вышла 27 декабря 2004 года. Его основные нововведения - возможность прикреплять файлы к сообщениям и создавать опросы.

Последняя версия из этой ветки, 2.6.11, была выпущена 17 декабря 2014 года. Ведется разработка YaBB 3.

На основе YaBB был создан аналогичный движок на PHP, использующий СУБД MySQL, получивший название YaBB SE . В свою очередь, он стал основой популярного ныне движка SMF (Simple Machines Forum) .

YaBB Original Release

Итак, устанавливаем самую первую версию YaBB. Стоит уточнить, что нижеприведенная инструкция справедлива для серверов, работающих на базе операционных систем типа Linux и FreeBSD.

Инсталлятор отсутствует, поэтому установка производится простым копированием файлов в папку cgi-bin (в текстовом режиме) и в папку для HTML-файлов (в бинарном режиме). Для файлов YaBB.pl , Printpage.pl , Search.pl , Reminder.pl устанавливаются соответствующие права доступа, позволяющие их выполнение (обычно 755). Учетная запись администратора уже создана (логин: admin, пароль: admin).

Однако начиная со 2-й половины 2000-х гг. YaBB начал терять свои позиции. Среди основных факторов, повлиявших на это, можно назвать распространение бесплатных движков, работающих на PHP и MySQL, а также хостингов с поддержкой этих технологий. Многие владельцы форумов перешли с YaBB на другие движки (как правило, на SMF).

Тем не менее, в отличие от других аналогичных движков (UBB, Ikonboard, UltraBoard и т.д.), YaBB не прекратил разработку, а продолжил выпускать новые версии, которые также написаны на Perl и хранят данные в текстовых файлах, но при этом по функциональности не уступают популярным бесплатным форумам на PHP и MySQL.

Теги: Добавить метки

По сути, единственное достоинство CGI .pm - это его "стандартность" и "поддерживаемость". Все остальное (включая то, что он не поддерживает имена полей форм в стиле PHP) можно отнести к недостаткам. Я так думаю.

Андрей Новиков[досье] к тому, что краткая реплика

CGI::Cookie uses CGI => в отстой.

с последующим подтверждением Алексей Севрюков[досье] может быть превратно понята, так, что CGI .pm не следует использовать вообше. Учитывая Ваш авторитет на форуме, можно сказать, что найдутся люди, для которых этой Вашей фразы будет достаточно для полного отказа от CGI.pm. Вот для них и будет полезным ознакомиться с другой точкой зрения.

Alexander O[досье]
В таком случае мне придется поддержать Андрея Новикова. Производительнось CGI .pm оставляет желать много лучшего. В свое время я заменил его в форуме YaBB на несколько тривиальных самописных функций, что увеличило скорость ответов на порядок (благодаря CGI.pm YaBB до этого страдал серьезной "тормознутостью") и снизило расход памяти где-то в два раза. Если есть нужные знания, то пользоваться CGI.pm лучше не стоит.

Владимир Палант[досье] imho, самописные функции вместо CGI .pm несомненно могут использоваться, только это нужно рассматривать как исключение . В точности как с правилом use strict; . И на отказ от общего правила, что со strict, что с CGI.pm, можно пойти только отчетливо представляя, что приобретаешь, и чем рискуешь. Здесь все дело в оговорке "если есть нужные знания ".

К сожалению, используя CGI .pm тоже нужно отчетливо представлять, чем рискуешь. Какой-нибудь скрипт администрирования, у которого все равно больше одного пользователя не будет, с ним писать можно, а вот системы, на которые предполагается нагрузка - увольте.

Alexander O[досье] , я свою функцию разбора query string написал на второй день изучения Перла, еще ничего не зная о существовании CGI .pm (и слава богу, а то так бы ламером и остался). С тех пор (за 8 лет) она была только пару раз оптимизирована, и стала практически эквивалентна общепринятым решениям. О каких знаниях тут идет речь? Это же фундамент. Если не знаешь этого, то лучше идти в форум по PHP и спрашивать, почему кука в браузере не появляется сразу после вызова setcookie, а только при следующем "выполнении" скрипта.

Когда я писал не перле мне тормознутость CGI не нравилась, я писал свою библиотеку для работы с HTTP . Проблема в том, что встают нетривиальные задачи, вроде принятие загруженных файлов, разбор mutipart/form-data. Потом (с далнейшей доработкой) библиотека нагружается и становится такой же "неповоротливой", как CGI

Не буду спорить про скорость(она не высока, по этому aprlib рулит), но после одного случая стал больше доверять решениям в CGI .pm, нежели в остальных модулях(как и самопальных). Это единственный модуль на CPAN , который на тот момент делал правильно escaping строк в UTF-8(CGI::Util::escape), в отличии от модуля URI::Escape и самопальных реализаций в Mason"е и других приложениях. Вместо того чтоб так уж сильно критиковать CGI.pm, предложите альтернативу. Патчи Линкольном принимаются и это возможность улучшить как быстродействие, так и стабильность работы модуля.

Андрей Новиков[досье] Опять в точку. Я вот тоже начинал сразу без CGI и об этом модуле узнал уже после того как сделал разбор $ENV{QUERY_STRING}, и тоже счастлив что не стал его использовать. Так же я не видел что кто-то использует CGI.pm на все 100%, получается что зря компилится и занимает память куча мусора.
И как показывает практика, большинство кто использует CGI.pm максимум что используют так это param и cookies.

Закиров Руслан[досье] Никто Вам не мешает добавить в свой модуль кусок escaping"а из CGI.pm, ведь Вы скорее всего тоже не используете этот модуль на все 100%.

Следовательно делаю вывод что CGI.pm используют новички и говорят другим новичкам что это круто. И что его можно использовать если нужно быстро слепить какую-нибудь тестовую форму или еще что-нибудь.

Чтобы продолжать тему, думаю стоит на секунду остановиться и задуматься.
Откуда появилась Java?
Ведь Java жутко тормозной язык, использует неприличное количество памяти.
За то идеологически правильный, кроссплатформенный - скажут некоторые. Игры для мобильников пишут на Java, которые ужасно тормозные. Почему не на ассемблере? Ведь та же самая игра будет работать в 10 раз быстрее, "весить" меньше в 10 раз и использовать памяти также на порядок меньше.
Думаю ответы все знают.
Так же ситуация с CGI . Ныне разработчики (может, к сожалению) идут по пути не хорошей производительности, а по пути простого кода, совместимости.

Если хотите проблем на свою голову - можно написать свою быстренькую библиотечку, не беда, что она будет "дырявая" до 10-й версии, иметь меньшие функции и ее придется устанавливать вместе со своим проектом. Я уж не говорю про то время, которое можно потратить на изобретение велосипеда.

Ну касательно HTML , сугубо ИМХО, но генерировать HTML объектами — самое большое извращение, которе я встречал в программировании.

Алексей В. Иванов[досье] , дырявой она будет гораздо меньше. Плавали, знаем. CGI .pm тоже в ОС не зашито.

Андрей Новиков[досье] как посмотреть...
Модуль, которым пользуется бОльшая часть перл-сообщества хостеры обновят молча и без предупреждений, пока Вы дома попиваете кофе. А если Вы автор, то кто кроме Вас самих найдет и исправит ошибку?

Согласен с Алексей В. Иванов[досье] , так как если заглянуть в тот же escping сразу всплывает EBCDIC с который я не знаком даже был до этого, а тут оказывается IBM в свое время придумал какую-то фигню и теперь народу приходится мучится и конвертить туда-сюда из ASCII , а в своем бы коде это работало скорее всего не верно. Так же получилось с UTF-8. perl начал поддерживать многобайтные символы и соответственно ord стал их поддерживать и возвращать значения больше 255. Что сразу поломало следующую конструкцию:

S/([^a-zA-Z0-9_.!~*"()-])/uc sprintf("%%%02x",ord($1))/eg;

Которая используется повсеместно на CPAN "e. И все проекты, которые решают подобную задачу поломались. Включая URI::Escape, который по идее должен делать это лучше всех, сейчас это это пофикшено за счет дополнительной функции специально для utf-8(что тоже отстой полнейший), но в том же Mason"e каждый раз приходится использовать свой обработчик, потому что автор Mason"а, на отрез отказался принимать патч, который использует URI::Escape, а согласен принять поправки к приведенной строке(копи-паст из другого модуля по просту говоря), ну не маразм ли? И что так каждый раз, когда что-то не так? Увольте. Я не буду копировать из модуля или писать что-то свое для общих вещей.

Я просто ответил, что сейчас используется. Вы же развели оффтоп около CGI .pm, если бы вы просто сказали, что вы используете, то глядишь бы я сам пересмотрел свою систему сессий, когда бы увидел, что народ не ипользет, то что и я. Но еще раз скажу, что не буду использовать самописный модуль для чтения кукисов. Согласно профайлеру в остальном коде перл вращается много долше нежели в CGI.pm в сумме на каждые запрос сервера, пока это так меня больше волнует мой код и его абстрагирование от особенностей обработки кукисов.

Закиров Руслан[досье] , Вы еще раз доказали, что свои модули лучше всего, потому что четко понимаешь, что и как работает, и можешь оперативно внести в них изменения. Не хочу зависеть от всяких авторов Mason"а, по возможности.

Хочу заметить, что я не против CPAN . Наоборот, всяческое повторное использование кода мною приветсвуется, но ко всему этому надо подходить с умом и осторожно.

Андрей Новиков[досье] Опять в точку. А это ведь один из главных критериев (ИМХО). Свой модуль каждый знает досконально и знает как и что поправить и где дописать.

Опять же все зависит от задачи. Мне например не нужен Юникод в данный момент, но как только понадобится я возьму готовый кусок из другого модуля (из того же CGI) и вклиню его в свой модуль.

свои модули лучше всего, потому что четко понимаешь, что и как работает, и можешь оперативно внести в них изменения

Для чего лучше? Когда проект твой личный, и когда никто кроме тебя его в дальнейшем поддерживать и развивать не будет, то, со скрипом, но можно согласиться, что может и лучше, думая - "на вкус и цвет товарищей нет". Но если ты работаешь в команде, если делаешь разовый заказ, если проект настолько большой, что один человек с ним не справится, и кто-то будет настаивать на самописном модуле, то как к этому можно отнестись? Если у Вас, Андрей Новиков[досье] , и у Вас, Алексей Севрюков[досье] , нет доверия к общеупотребительным модулям со CPAN , то представьте, какое доверие может быть у других разработчиков к вашим. А насколько хорошо самописные модули документированы? И если тысячи разработчиков могут с листа читать код, использующий CGI .pm, то альтернативный модуль нужно будет каждому изучать.
Очень наивно полагать, что самостоятельно можно сделать что-то лучше, чем CGI.pm.
Мой опыт говорит о том, что перл-скрипт, может быть, в большинстве случаев, быть написан совершенно без всякой оптимизации по скорости и памяти, но читаемостью кода пренебрегать ни в коем случае нельзя. На моем сайте пасутся около полутысячи человек одновременно, а тормоза приходятся только на работу с БД, и это без mod_perl.

Alexander O[досье] , тезисно:

1. Никто не говорит, что пользоваться модулями нельзя. Я, например, пользуюсь DBI и еще десятком других.
2. Понимание, какие модули можно использовать, а какие нет — приходит постепенно.
3. Самописные модули пишутся не "лишь-бы не чужое" (начинается обычно как раз с них), а после осознания недостатков общеупотребительного решения, и пишутся они в глубокой задумчивости.
4. Свои модули пишутся в рамках и вылизываются под свой CMF, а не CMF подгоняется под синтаксис общеупотребительного модуля.
5. Я не умею "с листа" читать код с CGI .pm. Код, генерирующий HTML через CGI.pm вводит меня в ступор.
6. Мои модули являются моей интеллектуальной собственностью, и чем меньше человек в них разберется, тем больше денег я заработаю:).
7. Я никогда не буду работать в одной команде с человеком, полагающимся на CGI.pm.

Просьба всё это не воспринимать на свой счет. Мы просто высказываем наши "имхи".

Андрей Новиков[досье] И опять я соглашусь со всем выше сказанным.
Alexander O[досье] Разговор не идет о доверии к модулям с cpan, в данном случае я имею ввиду только CGI .pm, сам же я конечно же использую модули с CPAN предпочительно последних версий.
Я все равно не понимаю по поводу чего Вы спорите, Вы же не будете например генерить HTML через CGI.pm? Конечно нет, иначе бы Ваш проект загнулся. НО тогда зачем Вам куча ненужных функций в этом модуле? Чтобы красиво рабобрать и поставить куки достаточно 3 килобайт - а зачем мне запускать весь немерянный CGI.pm для это задачи?

Понятное дело, что все вышесказанное это IMHO . Я даже на эту тему спорить не хочу.
И все таки, Андрей Новиков[досье] , Алексей Севрюков[досье] к Вам максимально конкретный вопрос: вы в своих " CGI " (если, конечно, писали) реализовали механизм распарсивания "multipart/form-data" и сохранения uploaded файлов?

Алексей Севрюков[досье] хм:) Ладно про UTF я спрашивать не буду. Здорово, конечно, разобраться во внутренностях, ничего не говорю, но все-таки в повсеместно используемом модуле есть большой плюс для хостингов, когда все пользователи использют один модуль, то его байт-код не выгружается из памяти, кэшируется.

Алексей В. Иванов[досье] Не вопрос, если мне будет нужно, я перейду на mod_perl. Если же мне будет мало обычного хостинга, я возьму тяжелый, если будет мало тяжелого тогда выделенный сервер. Все как всегда зависит от задачи.
По поводу UTF - пока не нужен - его там не будет. Понадобится - приделаю.

Алексей В. Иванов[досье]
Не выгружается? Вы про mod_perl? Так там уж точно никакого смысла в CGI .pm нет, Apache::Request сделает все то же самое, но во много раз быстрее. А других реальных способов кешировать байт-код вроде и нет...

Алексей В. Иванов[досье] , конечно, как Вы иначе сюда иллюстрации подгружаете? Кстати, код был взят из публичного модуля, содержал кучу ошибок, которых мы наелись в старом Xpoint и был кропотливо исправлен одним небезызвестным тут человеком:).

Андрей Новиков[досье] чего только не узнаешь во время оффтопика:) Оказывается xpoint на perl:)
Ну в общем чего тут продолжать. Вывод думаю, один: есть много времени - пиши свой модуль, нет времени, используй готовый.

Алексей В. Иванов[досье] На свой модуль много времени не нужно. Понадобился мне например специфичный модуль для файлов типа ini, сел и написал за часик (и то это долго, просто я все красиво и продуманно делал, с расчетом на недалекое будущее), когда понадобились в нем новые возможности - быстренько минут за 10-15 приписал и все дела.

Alexander O[досье] Ведь все равно найдется что-то что не сможет сделать CGI .pm, тогда его тоже будут иправлять и наращивать. Разница лишь в том, что ждать новой версии дольше, чем сделать самому. И так не бывает как вы говорите "Не пришлось бы ничего исправлять", исправлять всегда есть что. Никакая с нуля написанная сложная система без исправлений работать не будет, и не только с нуля. Мы все люди и мы все ошибаемся, Линкольн Штайн тоже человек и он тоже может ошибаться.

Алексей В. Иванов[досье] , а Вы думали на чем?

Alexander O[досье] , почему? Я же сказал, что код был тоже с CPAN . Я не помню, что именно исправлялось, что-то там с обработкой boundary, тогда можно было бы посмотреть, есть ли такая проблема в CGI .pm.

Андрей Новиков[досье] код был из CGI::Lite, насколько я помню. А на CPAN всякое есть, даже котеровские WebIN, WebOut (Дмитрий, не обижайся, это я любя)

Чтоб не переливать из пустого в порожнее даю ссылку на длинную дискуссию CGI.pm or roll-your-own? , где прозвучали, наверное, все аргументы за и против.

Еше, вот ссылка на сбывшуюся мечту, CGI.pm, c вырезанной поддержкой генерации HTML , CGI::Simple , и небольшое обсуждение , о том как CGI::Simple делает CGI.pm в два раза по скорости.

Я тоже провел сравнение и получил вот, что:

Use Benchmark qw(:all); print "Module Loading\n"; cmpthese(100, {CGI => sub {do{require CGI; undef %INC}}, Simple => sub {do{require CGI::Simple; undef %INC}}, }); print "New process creation testing\n"; $n = 100; $start = time; `perl -MCGI -e ""` for 1 .. $n; print "CGI: " . (time() - $start) . " ($n)\n"; $start = time; `perl -MCGI::Simple -e ""` for 1 .. $n; print "CGI::Simple: " . (time() - $start) . " ($n)\n";

Module Loading Rate CGI Simple CGI 14.8/s -- -4% Simple 15.5/s 4% -- New process creation testing CGI: 8 (100) CGI::Simple: 8 (100)

Что-то не видно разницы. (Я сравнивал последние версии модулей CGI 3.05 и CGI::Simple 0.075)
А по памяти CGI::Simple меньше чем CGI на 56kb (Linux Debian)

Ну и что они в этот CGI::Simple понапихали? Для сравнения — у меня класс отвечающий за пришедший HTTP запрос занимает 12KB, при этом он умудряется распарсить GET и POST, обработать файлы в multipart/form-data, разобраться с куками и прозрачно работать со сложными составными полями (например ввода даты из нескольких input"ов и select"ов). Больше ничего нормальному человеку от этого класса не нужно.

Alexander O[досье]
Проведите сравнение в реальной системе, желательно с помощью ab (ApacheBench). Я не смотрел CGI::Simple, но уверен, что результаты будут тогда совершенно иными. Как я уже писал выше - для YaBB скорость обработки запросов (реальная - загрузка страниц, а не абстрактные цифры Benchmark"а) без CGI.pm увеличилась в несколько раз, причем даже очень заметно для пользователей.

сообщение промодерировано

Да... Такого количества ошибочных утверждений я не видел давно.

Андрей Новиков[досье] где вы в модуле CGI::Cookie увидели use CGI; ???
Он юзает только три функции из CGI::Util - rearrange, unescape, escape
http://search.cpan.org/src/LDS/CGI.pm-3.05/CGI/Cookie.pm

Андрей Новиков[досье]

Да невозможно улучшить модуль размером в 225 КВ, из которых 95% являются мусором. Если бы он разбил его на 10 маленьких модулечков, то тогда можно было бы о чем-то говорить.

и Алексей Севрюков[досье]

Конечно нет, иначе бы Ваш проект загнулся. НО тогда зачем Вам куча ненужных функций в этом модуле? Чтобы красиво рабобрать и поставить куки достаточно 3 килобайт - а зачем мне запускать весь немерянный CGI.pm для это задачи?

А экспортировать отдельные функции вы не умеете? Этот модуль - отличный пример динамического подгружения.

Замечу, что никто из вас пока не показал свой "лисапет" и не привел реальные бенчмарки.

Владимир Палант[досье]

реальная - загрузка страниц, а не абстрактные цифры Benchmark

эээ.. с каких это пор реальная скорость работы скрипта меряется загрузкой страниц?

NeoNox Neon[досье]
Вы здесь самый умный?

Как вы думаете, чем пользователь смотрит скрипт? Правильно, браузером, страницы загружает. Поэтому ApacheBench часто дает более полную картину, поскольку показывает и старт интерпретатора, резервирование памяти и компиляцию модулей. А с Benchmark многое просто не измерить.

http://www.yabbforum.com) в почти неизменном виде, см. функции header() и cookie() в Subs.pl (совместимы с CGI .pm, иначе были бы еще проще). Там же я в свое время подкорректировал функцию readform(). Ничего сложного там нет. Бенчмарки когда-то были в форуме, но сейчас их уже удалили и делать их заново мне лень.

Насчет "экспортировать отдельные функции" - мои замеры четко показывали, что это не помогает.

сообщение промодерировано

Владимир Палант[досье]
Вы здесь самый умный?
хмм... Это реакция на слово "лисапет"?

Мой "лисапет" давно уже вошел в официальную версию YaBB (http://www.yabbforum.com) в почти >неизменном виде, см. функции header() и cookie() в Subs.pl

Спасибо, посмотрю.

Как вы думаете, чем пользователь смотрит скрипт? Правильно, браузером, страницы загружает. Поэтому ApacheBench часто дает более полную картину, поскольку показывает и старт интерпретатора, резервирование памяти и компиляцию модулей. А с Benchmark многое просто не измерить.

Дело в том, что термин "загрузка страницы" это как у солдат "отсюда и до обеда".
У вас упал канал и вы долго грузите то что остальным доступно влет.
Если вы имели ввиду тестирование ApacheBench то вопросов у меня нет. Покрайней мере пока я не увидел ваши модули.

Насчет "экспортировать отдельные функции" - мои замеры четко показывали, что это не помогает.

В чем не помогает? При экспортировании только param загружаются в память все остальные методы?

Кстати, размер кода CGI .pm ну никак не влияет ни на его скорость работы, ни на скорость его загрузки. Кто-нибудь вообще смотрел, как он внутри устроен? Новые версии CGI::WebIn, кстати, точно так же работают.

NeoNox Neon[досье] , есть мнение, что на localhost канал не падает. Касательно use/не-use — я заглянул в CGI::Cookie один раз и давно. Если с тех пор что-то изменилось, я за них очень рад. Но бросаться из-за этого и переписывать давно работающий и отлаженый код на использование CGI я не собираюсь.

сообщение промодерировано

Андрей Новиков[досье]

есть мнение, что на localhost канал не падает.

есть мнение что функии header() и cookie() не могут отжирать огромное количество памяти и ресурсов процесора. это каким радиусом кривизны рук нужно обладать что-бы сотворить "шедевр" на этих безобидных вещах занимающих несколько десятков строк кода?

Как ни крути, а модуль на 225 Kb будет чистаться и компилится дольше чем модуль на 10 Kb (при условии что в 10 кб почти похожие функции). Даже если там и используется грамотный экспорт.
Ведь это же физика, сперва надо прочитать файл с диска, я понимаю что разница минимальная, но она есть уже на этом этапе, потом Perl должен все это дело скопмидировать и разумеется он будет 225 килобайт анализировать и компилить дольше, чем 10 килобат. IMHO .

сообщение промодерировано

Ладно, любителям динамической загрузки конкретные цифры по расходу памяти (Windows, смотрел по Task Manager):

use CGI; - 1104 kB
use CGI (); - 1104 kB
use CGI qw(header cookie); - 1104 kB
use CGI qw(:standard); - 1188 kB

Итого: одна лишь загрузка CGI .pm сжирает более одного MB памяти, причем независимо от того, что импортируется. Вывод: верьте своим глазам, а не утверждениям авторов модулей. Динамическая загрузка отличная вещь, но что-то там все-таки не так.

сообщение промодерировано

А так если продолжить про CGI , то под mod_perl(я так понял) этот модуль перепрыгивает на разбор через Apache::Request, и проведенные бенчмарки(ab) говорят, что прямое использование A::R не дает заметного прироста производительности. Размеры модуля - минус безусловно.

Владимир Палант[досье]

perl -e ""	1428 kb
perl -MCGI -e ""	2604 kb
perl -MCGI::Util -e ""	2024 kb
perl -MCGI::Simple -e ""	2628 kb !!!
perl -MDBI -e ""	3212 kb
perl -MList::Util -e ""	2260 kb
perl -MHTML::Template -e ""	2768 kb

DBI будем переписывать? :)

Aндрей, а твой модуль сколько памяти ест?

# perl -MBenchmark=:all -de0
DB <1> sub a1 () { system ("perl","-e","require CGI ;"); }

DB<2> sub a2 () { system ("perl","-e","require CGI::Cookie;"); }

DB<3> sub a3 () { system ("perl","-e","require CGI::Lite;"); }

DB<4> timethese (10_000,{"A1" => \&a1,"A2" => \&a2,"A3" => \&a3})
Benchmark: timing 10000 iterations of A1, A2, A3...
A1: 334 wallclock secs (1.24 usr 10.11 sys + 281.30 cusr 41.92 csys = 334.57 CPU) @ 881.06/s (n=10000)
A2: 223 wallclock secs (1.29 usr 9.41 sys + 175.33 cusr 36.04 csys = 222.07 CPU) @ 934.58/s (n=10000)
A3: 118 wallclock secs (1.06 usr 9.40 sys + 77.59 cusr 28.94 csys = 116.99 CPU) @ 956.02/s (n=10000)
^D
# perlbloat CGI
CGI added 608k
# perlbloat CGI::Cookie
CGI::Cookie added 172k
# perlbloat CGI::Lite
CGI::Lite added 140k
#

Не хило для модуля размером в 8 kB...

из них 140 кб берет use strict , и больше 200кб require Exporter

Дмитрий Котеров[досье] а Вы что думаете, я тут про CGI .pm рассуждаю, а сам исходников не видел? Нет, я не говорю о том, чего не знаю.

Андрей Новиков[досье]

Я не умею "с листа" читать код с CGI .pm. Код, генерирующий HTML через CGI.pm вводит меня в ступор.

Вот здесь, CGI.pm HTML-Generation Methods Considered Useful , мне кажется, хорошо, хотя и не полно, показано удобство генерирования HTML через CGI.pm. Только не надо сразу шашками махать, потому что автор четко ограничивает область применимости такого подхода. Для административных интерфейсов, когда только и надо, что табличку со статистикой показать, я обычно так и делаю. И даже при работе с шаблонами, бывает очень удобно генерировать элементы HTML форм через CGI.pm - писанины меньше.

И терпентин на что-нибудь полезен! /К. Прутков/

Владимир Палант[досье] Я читал это. Вообщем-то можно посидеть потратить время на избавление от всего, что можно заменить на libapr.

Пока было предложено использовать самописную реализацию или libapr(только mod_perl), а что делать остальным, кто не может реализовать предложеное, которых скорее всего большинство?

про размер кода и производительность уже было сказано выше, поэтому я хочу сказать о другом - о концепутальности в программировании или об элегантности кода, которая если кому известно, "окупается всегда".

помимо вышесказанного, CGI .pm - это безусловное зло еще и потому что:
- своим названием компроментирует интерфейс CGI, к которому данный модуль (как впрочем и никакой другой) отношения не имеет.
- сочетает в себе методы, относящиеся к разным слоям (например, разбор входных данных и тут же форматирование вывода), чем приучает разработчика к принципиально неправильным "техникам" программирования.
- не концептуальная реализация (например принудительное выставление кодировки по умолчанию) вызывает проблемы, которые неопытным разработчикам сложно даже просто найти (не говоря уж об исправлении).

И самое ужасное, что не относится к самому модулю, но напрямую с ним связано: этот модуль попал практически во все книжки по программированию на Perl, чем способствовал (и, блин, поспособстовал же!) формированию неправильных подходов к программированию у начинающих разработчиков.

Alexander O[досье] Нет не смущает.

Свою работу cgi-lib делает нормально и это главное
(Вообще я часто встречал упоминания о том, что замена CGI это cgi-lib, не только в интернете, но и в книгах)

сообщение промодерировано

Тут, по-моему, все очевидно:
За: все написано за тебя, бери и пользуйся
Против: неприемлимо на высоких нагрузках. Хотя они должны быть весьма значительными, что бы был видимый для пользователя эффект.

Serega[досье] Это все равно что сказать "я так понял, лучше не ездить на изделиях отечественного автопрома". Ездить можно. Только не очень быстро.

Тут речь идет не о приемлимости использования как о факте, а о приемлимости использования в определенных условиях.

Не много об использовании памяти:

> perlbloat "use CGI qw(:standard);" use CGI qw(:standard); added 628k > perlbloat "use CGI qw();" use CGI qw(); added 624k > perlbloat "use CGI;" use CGI; added 624k > perlbloat "use CGI::Util;" use CGI::Util; added 128k > perlbloat "use CGI::Cookie;" use CGI::Cookie; added 180k

Владимир Палант[досье]
Специально для вас 128 от 628 никак не половина, а чуть больше одной пятой, а точнее 20.4%.

А с учетом того, что вы не все считаете, получается и того меньше:

> perlbloat "use CGI qw(-compile:all);" use CGI qw(-compile:all); added 2.0M

arto[досье] Надуман, тем что Dummy модуль, который я загружаю ничего не содержит, а загружается немногим быстрее.

Дмитрий Котеров[досье] Нет, Unicode отключен по умолчанию. Даже если включен(use utf8), то при загрузке кода влияет в основом на константы в тексте только. Дополнительная память выделяется при работе непосредственно над строками. В общем в данном случае уникод зря приписали.

А так если интересно, то ИМХО на хранение undef значения(не считая записей в пространство имен и так далее, только структура скаляра) в 5.8 тратиться 12 байт, на пустую строку 16 байт.

Закиров Руслан[досье]
Не стоит переходить на личности только из-за того, что у вас получились другие результаты. Представьте себе, считать я умею. Проверяю ещё раз:

	Perl 5.6.1/Win32	Perl 5.8.4/Win32	Perl 5.8.1/Linux
use CGI::Util qw(rearrange make_attributes unescape escape expires)	512kb	552kb	604kb
use CGI::Util;	436kb	552kb	600kb
use CGI qw(:standard)	1204kb	1260kb	1180kb
use CGI qw(:header)	1112kb	1116kb	1152kb
use CGI qw(:header);header()	1340kb	1320kb	1308kb
use CGI::Cookie	632kb	680kb	728kb
use Dummy	44kb	36kb	120kb

Сравнивать что-либо с use CGI qw(-compile:all) — чушь, никому не нужны абсолютно все функции CGI.pm. Но характерно то, что вызов одной лишь функции header() заставляет откомпилироваться десяток других функций и ещё раз существенно увеличивает расход памяти.

GTop у меня под Linux не захотел становиться, так что я просто вызывал top -p $$ -b -n 1 перед загрузкой модуля и после неё. Чуть меньше половины расхода под Linux можно списать, если не учитывать shared memory (хотя я не вижу, на каких основаниях — у нас не mod_perl), но даже так до ваших цифр ещё далеко. Под Windows проверял по task manager"у, так как нормального модуля для определения расхода памяти не нашёл, а возиться самому с Win32::API лень.

Владимир Палант[досье]
Если смотреть на изменение объема расходуемой памяти не пустой программы, а, например, такой:

#!perl -wl use strict; use DBI; use HTML::Template; #use CGI::Util qw(rearrange make_attributes unescape escape expires);

то для WinXP, Perl 5.8.3 получаем следующие цифры:

Итого, при самой большой добавке 904kb, при десяти одновременных подключений к расходу памяти добавится 9MB, при сотне одновременных подключений (без mod_perl) добавится 90MB. Много? А много ли нынче серверов у которых меньше гигабайта оперативной памяти? Экономим на спичках, получаем геморрой.

Alexander O[досье]
Да, много. Сервер свой гигабайт памяти может с гораздо большим толком потратить (как ни странно, ваш скрипт обычно выполняется на сервере не один). И времени много уходит (в частности на компиляцию по востребованию, от которой так мало толку). У меня в реальных приложениях разница была заметна и сильно. Но это — надо смотреть, что вы программируете и где это будет использоваться.

Я лично не спорю, что сама CGI .pm зло для маштабируемости, но не считаю, что из этого следует, что CGI::Cookies/CGI::Util тоже вселенское зло. Согласен, что +904кб на скрипт это многовато, да и скорость не CGI.pm сахар.

Провел иследование с помощью top, список предварительно загруженых модулей взял из CGI::Util, и вообщем-то эти модули чаще всего подгружены уже(может быть за исключением Exporter).

BEGIN{system("top -p $$ -b -n 1")} BEGIN{use strict} BEGIN{system("top -p $$ -b -n 1")} BEGIN{require Exporter;} BEGIN{system("top -p $$ -b -n 1")} BEGIN{use vars qw($dummy)} BEGIN{system("top -p $$ -b -n 1")} BEGIN{use CGI::Util} BEGIN{system("top -p $$ -b -n 1")} PS. WebIn заинтересовал. Я так понимаю он написан как XS модуль? Это не есть гуд конечно, бо на хостингах может не стоять (и скорее всего не стоит).

Что касается исходников — а Вы не задумывались, что свои модули пишут не ради самого написания, а в личных корыстных целях? Потому и не выкладывают.

Из Вашего высказывания по поводу отладки я понял, что Вы вообще своих программ не пишите, только пользуетесь чужими?

Из Вашего высказывания по поводу отладки я понял, что Вы вообще своих программ не пишите, только пользуетесь чужими?

Нет, просто прежде чем критиковать хорошо отлаженный модуль - надо что-то предложить свое. Скажем так - критикуя предлагай, по моему это общепринятое мнение. Я ничего не критикую в ваших "супер секретных" модулях, я просто спросил - кто их отлаживал кроме вас самих?

З.Ы.
Не хотелось бы переходить на личности, но вы уже это делаете, так что небольшой камешек в огород
Владимира Палант"а -> в YaBB немешало бы переписать и функцию шифрования паролей, ибо это просто детсад (base64 - рулит для 91 года). Вы в гонке за производительностью не видите ущерб безопасности.
З.Ы.Ы По меньше снобизма господа, поменьше...

PoizOn[досье]
Никто не выкладывает свой код ещё и по той простой причине, что пишут его опытные программисты для себя, и поддерживать его они хотят исключительно в своих приложениях. Для менее опытных было два предложения, отлаженные решения с качеством кода на несколько порядков выше CGI .pm: cgi-lib и CGI::Lite. Против последнего, правда, говорит то, что в нём есть две ошибки, которые автор до сих пор не исправил. В остальном же модуль весьма эффективный и надёжный.

Это всё касается лишь разбора multipart-данных, что является весьма нетривиальной задачей. Если это не нужно, то хорошее и заточенное под соответствующую задачу решение может написать практически любой программист с годиком опыта программирования на Perl. Если помните, речь изначально шла о разборе кук.

PS: И не надо переходить на личности. К разработке YaBB я никакого отношения не имею. Я всего лишь попытался заточить его под свои нужды, а заодно уже вернуть свои модификации разработчикам. В процессе я разочаровался в их квалификации и YaBB больше не использую.
PPS: Да, попрошу поменьше снобизма (он у вас заметен не только в этой теме).

Никто не выкладывает свой код

Все-таки я бы хотел заметить, что, по моему мнению, свой код не выкладывает "никто", а не выкладывают его плохие (или посредственные) программисты. У хорошего же программиста инстинкт выкладывания, по моему глубокому убеждению, в крови.

Да на самом деле было бы что выкладывать, как я уже писал выше (давно это было) - я просто почти вырезал куски из того же CGI .pm, чуть-чуть переделал под себя и все дела.

Думаю что под CGI писать что-либо серьезное не стоит. Я с надеждой смотрю на модуль mod_perlite (http://freshmeat.net/projects/mod_perlite/), который на мой взгляд позволил бы более популяризировать язык, да и увеличить кол-во проектов на perl на массовых хостингах.