Комментарии 38
P.S. Как-то некрасиво тут смотрится код, обернутый в <pre>. Есть ли способ сделать его покрасивее?Если Вас не пугает такая штука, как Vim, то можно открыть сорец в нём, а потом сделать :TOhtml
Выглядеть будет примерно так
my $hash = {
foo => 'foo',
bar => 123,
baz => undef,
};
Результат зависит от выбранной colorscheme.
0
Пусть у нас есть ссылка на хэш $hash...
0
А писать ещё стоит.
0
Познавательно, но в практическом смысле малоприменимо, т.к. выискивание наиболее быстрого способа присваивания экнономия на спичках, по-моему, в подавляющем большинстве случаев
+1
со старухи 10 копеек, зато с десяти старух уже рубль !
0
Согласен, в большинстве случаев на таких мелочах не стоит экономить. Однако (как справедливо заметил pavel_kudinov ), исследования подобного рода помогают лучше понять, прочувствовать perl - что уже весьма полезно.
На самом деле, я этот тест затеял потому, что пишу сейчас довольно специфичное приложение, которое не производит сложных вычислений или долгих запросов к БД, а просто должно быстро работать с нехитрыми данными в памяти. Отсюда и интерес к этим мелочам :)
На самом деле, я этот тест затеял потому, что пишу сейчас довольно специфичное приложение, которое не производит сложных вычислений или долгих запросов к БД, а просто должно быстро работать с нехитрыми данными в памяти. Отсюда и интерес к этим мелочам :)
+4
НЛО прилетело и опубликовало эту надпись здесь
Точно, забыл этот способ включить! Спасибо большое, обновил текст. Он, конечно, не самый быстрый (как и в случае хэша, прямое присваивание работает в 2.5 раза быстрее) - но его тут явно не хватало для полноты картины.
0
А способы типа @$list = ( 456, ... ) и @list = ( 456, ... ) не подходят, так как теряют значения остальных элементов массива. Как я сказал, я в данном тесте исходил из того, что элементы массива - соответствуют полям объекта, и некоторые из них мы обновляем.
0
Использовать map вместо foreach
0
Использовать 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.
0
Ага, видимо пора и тут написать disclaimer: я намеренно воздержался от комментариев касательно простоты, красоты и читабельности кода: perl слишком широк, чтобы ставить тут какие-то рамки. Пусть эти вопросы каждый решает для себя - я же лишь привожу факты ;)
На самом деле - конечно в данном случае map некрасиво, а for соответствует стилю. И конечно я в 99.99% случаев напишу for. Но ведь это не мешает включить в benchmark оба варианта, верно? ;)
На самом деле - конечно в данном случае map некрасиво, а for соответствует стилю. И конечно я в 99.99% случаев напишу for. Но ведь это не мешает включить в benchmark оба варианта, верно? ;)
0
Если хорошо подумать (не обязательно даже немного почитать perlguts), то тогда необходимость делать бенчмарк на очевидно нелепых вариантах отпадет, там, глядишь через год-два перейдете на C. Хотя, если начнете изучать, как это работает изнутри и почему именно те или иные варианты работают быстрее, то highload, зная внутренности, будет писать много проще. Когда перейдете на C, то будете писать задумываясь о том, какой машинный код генерирует компилятор, а еще позже начнете делать вставки ассемблера оптимизированные под MMX/SSE и разрядность CPU. Когда напишите свои массивы и хэши, которые будут использовать собственный менеджер памяти, то удивитесь, насколько быстрее это работает, если, конечно, грамотно напишите :-]
-1
Ну, мое развитие как программиста идет по спирали (как и все в этом мире). На С я уже писал (обработка графики и аудио), со стремлением к оптимизации, анализом сгенеренного компилятором кода и кусками на ассемблере. Затем сдвинулся в сторону web и беззаботно пересел на perl. Теперь вот снова столкнулся с высоконагруженными приложениями, уже в этой области :)
0
С Перла на Си? Не смешите меня. По сей день я ни разу не видел задачи веб-девелопмента, с которой нельзя было бы справится посредством Перла, а рисовать графику Перлом никто и не собирается. Для каждой задачи свой язык; Си в Вебе - тем более в свете так быстро развивающихся тенденций - это залог огромного провала в производительности процесса разработки.
0
Ты весьма категоричен :) В вебе все-таки есть места, где Си не только уместен, но и практически незаменим. Например - поисковики. Тот же Яндекс бы просто не выжил, если бы его индексаторы и особенно поисковые демоны были бы написаны на perl. Другой пример - рекламные сети. У всех (ну, всех не знаю, но за несколько ручаюсь) крупных баннерных сетей ядро написано на C/C++ (хотя все интерфейсы и прочие сервисные скрипты - конечно пишут на скриптовых языках).
0
Конечно есть! Но сколько их? Три? Я к тому, что рассуждать в духе "вы, пионеры, просто на Си ещё не писали, а так всё бы на нём делали" - это детский лепет. В Вебе есть применение для быстрого когда, но они узкоспецифические. 99% Веба - это интерфейсы с той нагрузкой, которую вполне тянет Perl плюс mod_perl или FastCGI.
0
Хотя я, конечно, никак не исключаю использования "быстрых" языков! Сам работаю в проекте рекламной системы, которая сильно завязана на этом вопросе, а потому знаю, о чём говорю ;).
0
Нет языка, который был бы панацеей от всех проблем =)
Участи Ц/Цпп в вебе, как и любого другого языка - это вопрос, требующий экономического обоснования. Если выгоднее (читай дешевле и быстрее при допустимом качестве) решить задачу на скриптовом языке, значит надо на нём и делать. Если задача требует высококачественого решения, значит надо её решать на компилируемых языках. Под "качеством" я имею в виду качественные характеристики - скорость, ресурсопрожорливость, обьём и т.п.
То же в принципе происходит и в других областях. К примеру, можно отказаться от широких возможностей апача и перейти на более аскетичный, но скоростной нгинкс.
Участи Ц/Цпп в вебе, как и любого другого языка - это вопрос, требующий экономического обоснования. Если выгоднее (читай дешевле и быстрее при допустимом качестве) решить задачу на скриптовом языке, значит надо на нём и делать. Если задача требует высококачественого решения, значит надо её решать на компилируемых языках. Под "качеством" я имею в виду качественные характеристики - скорость, ресурсопрожорливость, обьём и т.п.
То же в принципе происходит и в других областях. К примеру, можно отказаться от широких возможностей апача и перейти на более аскетичный, но скоростной нгинкс.
0
результат очевиден и без тестов.
три присваивания всяко будут быстрее, чем перебор массива с присваиванием.
три присваивания всяко будут быстрее, чем перебор массива с присваиванием.
0
Если изучать такие зависимости, то стоило сделать серию тестов n = 2,4,8,16,64, 256, 1024, 4096, 32768 (ну или примерно подобный числовой ряд) - это будет корректнее (такой-то способ хорош при малом n, a такой-то при больших)
0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Сравнение способов присваивания в perl