Эффективность индексации списка (python 2 против python 3)

Похоже, это артефакт некоторых сборок Python 3.2. Лучшая гипотеза на данный момент заключается в том, что все 32-битные сборки Intel имеют замедление, а 64-битные - нет. Читайте дальше для получения дополнительной информации.

Вы не провели достаточно тестов, чтобы что-то определить. Повторив ваш тест несколько раз, я получил значения от 0,31 до 0,54 для одного и того же теста, что является огромным разбросом.

Итак, я провел ваш тест с 10x числом и repeat=10, используя несколько разных установок Python2 и Python3. Отбрасывая верхний и нижний результаты, усредняя остальные 8 и разделив на 10 (чтобы получить число, эквивалентное вашим тестам), вот что я увидел:

 1. 0.52/0.53 Lion 2.6
 2. 0.49/0.50 Lion 2.7
 3. 0.48/0.48 MacPorts 2.7
 4. 0.39/0.49 MacPorts 3.2
 5. 0.39/0.48 HomeBrew 3.2

Итак, похоже, что 3.2 на самом деле немного быстрее с [99] и примерно такой же скоростью с [-1].

Однако на машине 10.5 я получил такие результаты:

 1. 0.98/1.02 MacPorts 2.6
 2. 1.47/1.59 MacPorts 3.2

Вернувшись на исходную (Lion) машину, я запустил 32-битный режим и получил следующее:

 1. 0.50/0.48 Homebrew 2.7
 2. 0.75/0.82 Homebrew 3.2

Итак, похоже, что важна именно 32-битность, а не Leopard vs. Lion, gcc 4.0 vs. gcc 4.2 или clang, аппаратные различия и т. д. Было бы полезно протестировать 64-битные сборки под Leopard, с разными компиляторами и т. д. ., но, к сожалению, моя коробка Leopard — это Intel Mini первого поколения (с 32-разрядным процессором Core Solo), поэтому я не могу провести этот тест.

В качестве еще одного косвенного доказательства я провел множество других быстрых тестов на Lion box, и оказалось, что 32-разрядная версия 3.2 примерно на 50% медленнее, чем 2.x, а 64-разрядная версия 3.2, возможно, немного быстрее, чем 2. Икс. Но если мы действительно хотим подтвердить это, кто-то должен выбрать и запустить настоящий набор тестов.

В любом случае, на данный момент я думаю, что при оптимизации ветки 3.x никто не прилагал особых усилий для сборки 32-битных i386 Mac. Что на самом деле является разумным выбором для них.

Или, наоборот, они даже не приложили особых усилий к 32-битному периоду i386. Эта возможность может объяснить, почему ОП видел, что 2.x и 3.2 давали одинаковые результаты на Linux-боксе, в то время как Отто Алмендингер видел, что 3.2 так же медленнее, чем 2.6 на Linux-боксе. Но поскольку ни один из них не упомянул, используют ли они 32-битный или 64-битный Linux, трудно понять, имеет ли это значение.

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

вот код, который иллюстрирует хотя бы часть ответа:

$ python
Python 2.7.3 (default, Apr 20 2012, 22:44:07) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> t=timeit.timeit('mylist[99]',setup='mylist=list(range(100))',number=50000000)
>>> print (t)
2.55517697334
>>> t=timeit.timeit('mylist[99L]',setup='mylist=list(range(100))',number=50000000)
>>> print (t)
3.89904499054

$ python3
Python 3.2.3 (default, May  3 2012, 15:54:42) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> t=timeit.timeit('mylist[99]',setup='mylist=list(range(100))',number=50000000)
>>> print (t)
3.9906489849090576

python3 не имеет старого типа int.

Python 3 range() — это Python 2 xrange(). Если вы хотите имитировать Python 2 range() в коде Python 3, вы должны использовать list(range(num). Чем больше num, тем больше будет разница с исходным кодом.

Индексация не должна зависеть от того, что хранится внутри списка, поскольку список хранит только ссылки на целевые объекты. Ссылки нетипизированы и все одного вида. Таким образом, тип списка является однородной структурой данных — технически. Индексация означает преобразование значения индекса в начальный адрес + смещение. Вычисление смещения очень эффективно с не более чем одним вычитанием. Это очень дешевая дополнительная операция по сравнению с другими операциями.