Комментарии 38
P.S. Как-то некрасиво тут смотрится код, обернутый в <pre>. Есть ли способ сделать его покрасивее?
Если Вас не пугает такая штука, как Vim, то можно открыть сорец в нём, а потом сделать :TOhtml
Выглядеть будет примерно так

my $hash = {

foo => 'foo',

bar => 123,

baz => undef,

};

Результат зависит от выбранной colorscheme.
Вот как-то рука не поворачивается использовать архаичный тег font. Я бы пропустил это через colorer, или хотя бы просто написал бледным цветом, но Хабр не пропускает атрибут style :(
но Хабр не пропускает атрибут style :(
Зато он пропускает тег <font> с атрибутом color :)
Эх... ладно, вспомнил font и сделал код сереньким - так получше смотрится.
Хорошо :) В планах - сравнить варианты представления констант, затем варианты представления данных ("объектов")... Ну и заявки тоже принимаются :)
Ок, а что именно про него интересно? Именно про DBI, или вообще сравнение разных оберток для работы с БД?
Познавательно, но в практическом смысле малоприменимо, т.к. выискивание наиболее быстрого способа присваивания — экнономия на спичках, по-моему, в подавляющем большинстве случаев
со старухи 10 копеек, зато с десяти старух уже рубль !
Скажем так: в некоторых задачах это действительно может оказать влияние ;)
Согласен, в большинстве случаев на таких мелочах не стоит экономить. Однако (как справедливо заметил посмотреть профиль pavel_kudinov), исследования подобного рода помогают лучше понять, прочувствовать perl - что уже весьма полезно.

На самом деле, я этот тест затеял потому, что пишу сейчас довольно специфичное приложение, которое не производит сложных вычислений или долгих запросов к БД, а просто должно быстро работать с нехитрыми данными в памяти. Отсюда и интерес к этим мелочам :)
НЛО прилетело и опубликовало эту надпись здесь
Точно, забыл этот способ включить! Спасибо большое, обновил текст. Он, конечно, не самый быстрый (как и в случае хэша, прямое присваивание работает в 2.5 раза быстрее) - но его тут явно не хватало для полноты картины.
НЛО прилетело и опубликовало эту надпись здесь
А способы типа @$list = ( 456, ... ) и @list = ( 456, ... ) не подходят, так как теряют значения остальных элементов массива. Как я сказал, я в данном тесте исходил из того, что элементы массива - соответствуют полям объекта, и некоторые из них мы обновляем.
НЛО прилетело и опубликовало эту надпись здесь
Использовать map вместо foreach - моветон. Цитирую perldoc perlstyle:
Avoid using grep() (or map()) or `backticks` in a void context, that is, when you just throw away their return values. Those functions all have return values, so use them. Otherwise use a foreach() loop or the system() function instead.
Ага, видимо пора и тут написать disclaimer: я намеренно воздержался от комментариев касательно простоты, красоты и читабельности кода: perl слишком широк, чтобы ставить тут какие-то рамки. Пусть эти вопросы каждый решает для себя - я же лишь привожу факты ;)

На самом деле - конечно в данном случае map некрасиво, а for соответствует стилю. И конечно я в 99.99% случаев напишу for. Но ведь это не мешает включить в benchmark оба варианта, верно? ;)
Я не в упрёк :), просто хотел обратить внимание людей, чтобы в реальной жизни они не писали такой код :). А для бенчмарка хороши любые - даже самые странные - варианты!
Если хорошо подумать (не обязательно даже немного почитать perlguts), то тогда необходимость делать бенчмарк на очевидно нелепых вариантах отпадет, там, глядишь через год-два перейдете на C. Хотя, если начнете изучать, как это работает изнутри и почему именно те или иные варианты работают быстрее, то highload, зная внутренности, будет писать много проще. Когда перейдете на C, то будете писать задумываясь о том, какой машинный код генерирует компилятор, а еще позже начнете делать вставки ассемблера оптимизированные под MMX/SSE и разрядность CPU. Когда напишите свои массивы и хэши, которые будут использовать собственный менеджер памяти, то удивитесь, насколько быстрее это работает, если, конечно, грамотно напишите :-]
Ну, мое развитие как программиста идет по спирали (как и все в этом мире). На С я уже писал (обработка графики и аудио), со стремлением к оптимизации, анализом сгенеренного компилятором кода и кусками на ассемблере. Затем сдвинулся в сторону web и беззаботно пересел на perl. Теперь вот снова столкнулся с высоконагруженными приложениями, уже в этой области :)
С Перла на Си? Не смешите меня. По сей день я ни разу не видел задачи веб-девелопмента, с которой нельзя было бы справится посредством Перла, а рисовать графику Перлом никто и не собирается. Для каждой задачи свой язык; Си в Вебе - тем более в свете так быстро развивающихся тенденций - это залог огромного провала в производительности процесса разработки.
Ты весьма категоричен :) В вебе все-таки есть места, где Си не только уместен, но и практически незаменим. Например - поисковики. Тот же Яндекс бы просто не выжил, если бы его индексаторы и особенно поисковые демоны были бы написаны на perl. Другой пример - рекламные сети. У всех (ну, всех не знаю, но за несколько ручаюсь) крупных баннерных сетей ядро написано на C/C++ (хотя все интерфейсы и прочие сервисные скрипты - конечно пишут на скриптовых языках).
Конечно есть! Но сколько их? Три? Я к тому, что рассуждать в духе "вы, пионеры, просто на Си ещё не писали, а так всё бы на нём делали" - это детский лепет. В Вебе есть применение для быстрого когда, но они узкоспецифические. 99% Веба - это интерфейсы с той нагрузкой, которую вполне тянет Perl плюс mod_perl или FastCGI.
В общем, есть разные области :) Есть (99%) просто сайты, а есть узкие места в высоконагруженных проектах.
НЛО прилетело и опубликовало эту надпись здесь
Хотя я, конечно, никак не исключаю использования "быстрых" языков! Сам работаю в проекте рекламной системы, которая сильно завязана на этом вопросе, а потому знаю, о чём говорю ;).
Нет языка, который был бы панацеей от всех проблем =)
Участи Ц/Цпп в вебе, как и любого другого языка - это вопрос, требующий экономического обоснования. Если выгоднее (читай дешевле и быстрее при допустимом качестве) решить задачу на скриптовом языке, значит надо на нём и делать. Если задача требует высококачественого решения, значит надо её решать на компилируемых языках. Под "качеством" я имею в виду качественные характеристики - скорость, ресурсопрожорливость, обьём и т.п.
То же в принципе происходит и в других областях. К примеру, можно отказаться от широких возможностей апача и перейти на более аскетичный, но скоростной нгинкс.
результат очевиден и без тестов.
три присваивания всяко будут быстрее, чем перебор массива с присваиванием.
Если изучать такие зависимости, то стоило сделать серию тестов n = 2,4,8,16,64, 256, 1024, 4096, 32768 (ну или примерно подобный числовой ряд) - это будет корректнее (такой-то способ хорош при малом n, a такой-то при больших)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.