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