Залагам на f4 :) - с надеждата, че join е реализиран интелигентно като "string builder". Отностно итерацията, залагам на итератора, като най-пестелив.

Много яко! А защо за версиите преди 3.0 се налага range = xrange? Така не става ли по-мързеливо => бавно?

@Стефан Кънев

Не съм особено изненадан от резултатите.

Изненадан съм, че не си изненадан. =-)

Малък ъпдейт. Днес попаднах на една страхотнa библиотека за работа с Python bytecode (обаче работи само на Python 2.x).

Ето как изглежда bytecode-а на f1 и f2:

slavi@slavi-desktop:~$ python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:29:17) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from byteplay import *
>>> from what import *
>>> print(Code.from_code(f1.func_code).code)

  4           1 LOAD_CONST           ''
              2 STORE_FAST           s

  5           4 SETUP_LOOP           to 27
              5 LOAD_GLOBAL          range
              6 LOAD_GLOBAL          N
              7 CALL_FUNCTION        1
              8 GET_ITER             

  5     >>   11 FOR_ITER             to 24
             12 STORE_FAST           i

  6          14 LOAD_FAST            s
             15 LOAD_CONST           'abcdefg'
             16 LOAD_FAST            i
             17 LOAD_CONST           7
             18 BINARY_MODULO        
             19 BINARY_SUBSCR        
             20 BINARY_ADD           
             21 STORE_FAST           s
             22 JUMP_ABSOLUTE        to 11
        >>   24 POP_BLOCK            

  7     >>   27 LOAD_FAST            s
             28 RETURN_VALUE         

>>> print(Code.from_code(f2.func_code).code)

 10           1 LOAD_CONST           ''
              2 STORE_FAST           s

 11           4 SETUP_LOOP           to 27
              5 LOAD_GLOBAL          range
              6 LOAD_GLOBAL          N
              7 CALL_FUNCTION        1
              8 GET_ITER             

 11     >>   11 FOR_ITER             to 24
             12 STORE_FAST           i

 12          14 LOAD_FAST            s
             15 LOAD_CONST           'abcdefg'
             16 LOAD_FAST            i
             17 LOAD_CONST           7
             18 BINARY_MODULO        
             19 BINARY_SUBSCR        
             20 INPLACE_ADD          
             21 STORE_FAST           s
             22 JUMP_ABSOLUTE        to 11
        >>   24 POP_BLOCK            

 13     >>   27 LOAD_FAST            s
             28 RETURN_VALUE         

Както може да се очаква, единствената разлика е в 20-та инструкция: BINARY_ADD vs INPLACE_ADD. С други думи, хубавата новина е, че f2 не е по-бавна заради bytecode компилатора.

По-рано написах, че интерпретатора обработва BINARY_ADD и INPLACE_ADD с идентичен код (разбирай copy-paste-нат код). В случая на конкатерниране на стрингове има няколко оптимизации в unicode_concatenate в Python/ceval.c. Хипотезата е, е че в един от двата случая в unicode_concatenate се минава през различен (по-бавен) if/else branch.

Предлагам да се дадат 15 бонус точки на първия, който разбере и оправи проблема =-).

Nice. Не знаех (а трябваше =-), че има нещо подобно in the box.

На byteplay попаднах случайно. В някакъв блог, пича го ползваше, за да си направи tail recursive call декоратор. Плюса на byteplay май е, че можеш да промениш кода и да го превърнеш отново във функция.

Busted Myth 2: ''.join е по-бърз от 'наивното' конкатениране на низове

При мен при всички тестове (и с 3, и с 2.5) f4 работи по-бързо от f1

Как си успял да ги постигнеш тези времена на първите 2 функции?

По втория начин =-).

Шегата настрана, по начина който и ти: просто си пуснах скрипта.

Хубаво е, че се постват повече цифри от хора с различни машини и версии. По това, което си дал изглежда някой е "работил" по тези проблеми в последните ревизии на Python.

В момента си ъпгрейдвам дистрибуцията и като завърши ще видя как изглеждат нещата при мен (с каквато версия на Python от Убунту са сметнали за стабилна тоя месец).