'{0}'. Format () быстрее, чем str () и '{}'. Format (), используя IPython% timeit и в противном случае используя чистый Python

По какой-то причине время IPython просто выключено (хотя при тестировании с более длинной форматированной строкой в ​​разных ячейках оно несколько улучшилось ). Возможно, выполнение в одних и тех же ячейках неверно, не знаю.

В любом случае, "{}" немного быстрее, чем "{pos}" который быстрее, чем "{name}" пока они все медленнее, чем str .

str(val) – самый быстрый способ преобразования объекта в str ; он непосредственно вызывает объекты __str__ , если он существует, и возвращает результирующую строку. Другие, такие как format (или str.format ), включают дополнительные накладные расходы из-за дополнительного вызова функции (для format ); обрабатывая любые аргументы, анализируя строку формата и затем вызывая __str__ их args .

Для методов str.format "{}" использует автоматическую нумерацию; из небольшого раздела в документах по синтаксису формата :

Изменено в версии 3.1: Спецификаторы позиционного аргумента могут быть опущены, поэтому '{} {}' эквивалентно '{0} {1}' .

то есть, если вы укажете строку формы:

 "{}{}{}".format(1, 2, 3) 

CPython сразу знает, что это эквивалентно:

 "{0}{1}{2}".format(1, 2, 3) 

С строкой формата, содержащей цифры с указанием позиций; CPython не может принимать строго возрастающее число (которое начинается с 0 ) и должно анализировать каждую отдельную скобку, чтобы получить ее право, замедляя процесс в этом процессе:

 "{1}{2}{0}".format(1, 2, 3) 

Вот почему им также запрещено смешивать эти два:

 "{1}{}{2}".format(1, 2, 3) 

вы получите хороший ValueError когда вы попытаетесь сделать это:

 ValueError: cannot switch from automatic field numbering to manual field specification 

он также захватывает эти позиционные PySequence_GetItem с помощью PySequence_GetItem который, я уверен, является быстрым, по крайней мере, по сравнению с PyObject_GetItem [см. следующий].

Для значений "{name}" CPython всегда есть дополнительная работа, связанная с тем, что мы имеем дело с ключевыми словами, а не с позиционными; это включает в себя такие вещи, как построение словаря для вызовов и генерация пути более LOAD команд байтового кода для загрузки key s и значений. Ключевая форма вызова функции всегда вводит некоторые накладные расходы. Кроме того, кажется, что захват фактически использует PyObject_GetItem который несет некоторые дополнительные накладные расходы из-за его родового характера.