Почему для объединения массивов numpy, чем списков, требуется больше времени? [Дубликат]

Я расскажу вам о секрете: лучший способ использовать timeit находится в командной строке.

В командной строке timeit выполняет правильный статистический анализ: он сообщает вам как долго длился самый короткий пробег. Это хорошо, потому что ошибка во времени положительна. Таким образом, самое короткое время имеет наименьшую ошибку. Невозможно получить отрицательную ошибку, потому что компьютер никогда не может вычислить быстрее, чем он может вычислить!

Итак, интерфейс командной строки:

%~> python -m timeit "1 + 2"
10000000 loops, best of 3: 0.0468 usec per loop

Это довольно просто, eh?

Вы можете настроить файл:

%~> python -m timeit -s "x = range(10000)" "sum(x)"
1000 loops, best of 3: 543 usec per loop

, который тоже полезен!

Если вы хотите несколько строк, вы можете либо использовать оболочку автоматическое продолжение или использование отдельных аргументов:

%~> python -m timeit -s "x = range(10000)" -s "y = range(100)" "sum(x)" "min(y)"
1000 loops, best of 3: 554 usec per loop

Это дает настройку

x = range(1000)
y = range(100)

и времени

sum(x)
min(y)

Если вы хотите чтобы иметь более длинные скрипты, у вас может возникнуть соблазн перейти на timeit внутри скрипта Python. Я предлагаю избегать этого, потому что анализ и синхронизация просто лучше в командной строке. Вместо этого я стараюсь создавать сценарии оболочки:

 SETUP="

 ... # lots of stuff

 "

 echo Minmod arr1
 python -m timeit -s "$SETUP" "Minmod(arr1)"

 echo pure_minmod arr1
 python -m timeit -s "$SETUP" "pure_minmod(arr1)"

 echo better_minmod arr1
 python -m timeit -s "$SETUP" "better_minmod(arr1)"

 ... etc

Это может занять несколько больше времени из-за множественных инициализаций, но обычно это не очень важно.

Но что если вы хотите использовать timeit внутри вашего модуля?

Ну, простой способ сделать:

def function(...):
    ...

timeit.Timer(function).timeit(number=NUMBER)

, и это дает вам кумулятивное ( not минимум!) время для запуска этого количества раз.

Чтобы получить хороший анализ, используйте .repeat и возьмите минимум:

min(timeit.Timer(function).repeat(repeat=REPEATS, number=NUMBER))

Обычно вы должны комбинировать это с functools.partial вместо lambda: ..., чтобы снизить накладные расходы. Таким образом, у вас может быть что-то вроде:

from functools import partial

def to_time(items):
    ...

test_items = [1, 2, 3] * 100
times = timeit.Timer(partial(to_time, test_items)).repeat(3, 1000)

# Divide by the number of repeats
time_taken = min(times) / 1000

Вы также можете сделать:

timeit.timeit("...", setup="from __main__ import ...", number=NUMBER)

, который даст вам что-то ближе к интерфейсу из командной строки, но в гораздо менее прохладной манере. "from __main__ import ..." позволяет вам использовать код из вашего основного модуля внутри искусственной среды, созданной timeit.

Стоит отметить, что это удобная обертка для Timer(...).timeit(...), и поэтому она не особенно хороша в время. Я лично предпочитаю использовать Timer(...).repeat(...), как я показал выше.

Предупреждения

Есть несколько предостережений с timeit, которые находятся повсюду.

• Накладные расходы не учитываются. Скажите, что хотите время x += 1, чтобы узнать, сколько времени занимает добавление:

  >>> python -m timeit -s "x = 0" "x += 1"
  10000000 loops, best of 3: 0.0476 usec per loop
  

  Ну, это не 0.0476 мкс. Вы только знаете, что это меньше , чем это. Вся ошибка положительная. Поэтому попробуйте найти чистые накладные расходы:

  >>> python -m timeit -s "x = 0" ""      
  100000000 loops, best of 3: 0.014 usec per loop
  

  Это хорошая 30% накладных расходов только с момента! Это может значительно исказить относительные тайминги. Но вы действительно заботились о добавлении таймингов; временные интервалы поиска для x также должны быть включены в накладные расходы:

  >>> python -m timeit -s "x = 0" "x"
  100000000 loops, best of 3: 0.0166 usec per loop
  

  Разница не намного больше, но она есть.
• Методы мутации опасны.

  >>> python -m timeit -s "x = [0]*100000" "while x: x.pop()"
  10000000 loops, best of 3: 0.0436 usec per loop
  

  Но это совершенно неверно! x - это пустой список после первой итерации. Вам нужно будет повторно инициализировать:

  >>> python -m timeit "x = [0]*100000" "while x: x.pop()"
  100 loops, best of 3: 9.79 msec per loop
  

  Но тогда у вас много накладных расходов. Учтите это отдельно.

  >>> python -m timeit "x = [0]*100000"                   
  1000 loops, best of 3: 261 usec per loop
  

  Обратите внимание, что вычитание служебных данных здесь разумно только потому, что накладные расходы являются малой частью времени. Для вашего примера стоит отметить, что и Sorting Sort и Tim Sort имеют совершенно необычное временное поведение для уже отсортированных списков. Это означает, что вам понадобится random.shuffle между сортировками, если вы хотите избежать разрушения ваших таймингов.