Быстрее ли использовать n = len (s) вместо непосредственного использования len (s)? - PullRequest
Новая
       22

Быстрее ли использовать n = len (s) вместо непосредственного использования len (s)?

0 голосов
/ 28 ноября 2018

Часто, чтобы сэкономить время, я хотел бы, чтобы мы использовали n = len (s) в моей локальной функции.Мне интересно, какой вызов быстрее или они одинаковы?

while i < len(s):
  # do something

против 

while i < n:
  # do something

Разницы не должно быть слишком много, но, используя len (s), сначала нужно достичь s, затем вызвать s. length .Это O (1) + O (1).Но, используя n, это O (1).Я так полагаю.

Ответы [ 2 ]

0 голосов
/ 28 ноября 2018

Вы правы, вот несколько тестов: 

s = np.random.rand(100)
n = 100

Выше приведена настройка. 

%%timeit
50 < len(s)

86.3 ns ± 2.4 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

В сравнении: 

%%timeit
50 < n

36.8 ns ± 1.15 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

Но опять же, этоТрудно представить разницу на уровне ~ 60 нс, что сказалось бы на скорости.Если вы не звоните len(s) миллионы раз.

0 голосов
/ 28 ноября 2018

это имеет , чтобы быть быстрее.

  • Используя n вы просматриваете переменные (словари) один раз.
  • Используя len(s)вы смотрите дважды (len также является функцией, которую мы должны искать).Затем вы вызываете функцию.

Тем не менее, если вы делаете while i < n: большую часть времени, вы можете избежать использования классического цикла for i in range(len(s)):, поскольку верхняя граница не изменяется, и оценивается один раз.только при запуске в range (что может привести к: Почему бы мне не выполнить итерацию непосредственно по элементам или использовать enumerate? )

while i < len(s) позволяет сравнить вашииндекс против меняющегося списка.В этом весь смысл.Если вы исправите границу, она станет менее привлекательной.

В цикле for легко пропустить приращения с помощью continue (так же просто, как забыть увеличить i и получитьбесконечный while цикл)

...