Почему перебор небольшой строки медленнее, чем перебора небольшого списка?

132

Я играл с timeit и заметил, что выполнение простого понимания списка для небольшой строки занимает больше времени, чем выполнение той же операции со списком небольших односимвольных строк. Любое объяснение? Это почти в 1,35 раза больше времени.

>>> from timeit import timeit
>>> timeit("[x for x in 'abc']")
2.0691067844831528
>>> timeit("[x for x in ['a', 'b', 'c']]")
1.5286479570345861

Что происходит на более низком уровне, что вызывает это?

python performance cpython timeit python-internals Санджай Варма
источник

Ответы:

193

TL; DR

  • Фактическая разница в скорости приближается к 70% (или больше) после удаления большого количества накладных расходов для Python 2.

  • Создание объекта не виновато. Ни один из методов не создает новый объект, так как односимвольные строки кэшируются.

  • Разница неочевидна, но, вероятно, возникает из-за большего количества проверок индексации строк с точки зрения типа и правильности. Также вполне вероятно, благодаря необходимости проверить, что возвращать.

  • Индексирование списков происходит очень быстро.

>>> python3 -m timeit '[x for x in "abc"]'
1000000 loops, best of 3: 0.388 usec per loop

>>> python3 -m timeit '[x for x in ["a", "b", "c"]]'
1000000 loops, best of 3: 0.436 usec per loop

Это не соответствует тому, что вы нашли ...

Значит, вы должны использовать Python 2.

>>> python2 -m timeit '[x for x in "abc"]'
1000000 loops, best of 3: 0.309 usec per loop

>>> python2 -m timeit '[x for x in ["a", "b", "c"]]'
1000000 loops, best of 3: 0.212 usec per loop

Поясним разницу между версиями. Я изучу скомпилированный код.

Для Python 3:

import dis

def list_iterate():
    [item for item in ["a", "b", "c"]]

dis.dis(list_iterate)
#>>>   4           0 LOAD_CONST               1 (<code object <listcomp> at 0x7f4d06b118a0, file "", line 4>)
#>>>               3 LOAD_CONST               2 ('list_iterate.<locals>.<listcomp>')
#>>>               6 MAKE_FUNCTION            0
#>>>               9 LOAD_CONST               3 ('a')
#>>>              12 LOAD_CONST               4 ('b')
#>>>              15 LOAD_CONST               5 ('c')
#>>>              18 BUILD_LIST               3
#>>>              21 GET_ITER
#>>>              22 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
#>>>              25 POP_TOP
#>>>              26 LOAD_CONST               0 (None)
#>>>              29 RETURN_VALUE

def string_iterate():
    [item for item in "abc"]

dis.dis(string_iterate)
#>>>  21           0 LOAD_CONST               1 (<code object <listcomp> at 0x7f4d06b17150, file "", line 21>)
#>>>               3 LOAD_CONST               2 ('string_iterate.<locals>.<listcomp>')
#>>>               6 MAKE_FUNCTION            0
#>>>               9 LOAD_CONST               3 ('abc')
#>>>              12 GET_ITER
#>>>              13 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
#>>>              16 POP_TOP
#>>>              17 LOAD_CONST               0 (None)
#>>>              20 RETURN_VALUE

Вы видите здесь, что вариант списка, вероятно, будет медленнее из-за создания списка каждый раз.

Это

 9 LOAD_CONST   3 ('a')
12 LOAD_CONST   4 ('b')
15 LOAD_CONST   5 ('c')
18 BUILD_LIST   3

часть. В строковом варианте есть только

 9 LOAD_CONST   3 ('abc')

Вы можете убедиться, что это действительно имеет значение:

def string_iterate():
    [item for item in ("a", "b", "c")]

dis.dis(string_iterate)
#>>>  35           0 LOAD_CONST               1 (<code object <listcomp> at 0x7f4d068be660, file "", line 35>)
#>>>               3 LOAD_CONST               2 ('string_iterate.<locals>.<listcomp>')
#>>>               6 MAKE_FUNCTION            0
#>>>               9 LOAD_CONST               6 (('a', 'b', 'c'))
#>>>              12 GET_ITER
#>>>              13 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
#>>>              16 POP_TOP
#>>>              17 LOAD_CONST               0 (None)
#>>>              20 RETURN_VALUE

Это дает только

 9 LOAD_CONST               6 (('a', 'b', 'c'))

поскольку кортежи неизменяемы. Тест:

>>> python3 -m timeit '[x for x in ("a", "b", "c")]'
1000000 loops, best of 3: 0.369 usec per loop

Отлично, вернемся к скорости.

Для Python 2:

def list_iterate():
    [item for item in ["a", "b", "c"]]

dis.dis(list_iterate)
#>>>   2           0 BUILD_LIST               0
#>>>               3 LOAD_CONST               1 ('a')
#>>>               6 LOAD_CONST               2 ('b')
#>>>               9 LOAD_CONST               3 ('c')
#>>>              12 BUILD_LIST               3
#>>>              15 GET_ITER            
#>>>         >>   16 FOR_ITER                12 (to 31)
#>>>              19 STORE_FAST               0 (item)
#>>>              22 LOAD_FAST                0 (item)
#>>>              25 LIST_APPEND              2
#>>>              28 JUMP_ABSOLUTE           16
#>>>         >>   31 POP_TOP             
#>>>              32 LOAD_CONST               0 (None)
#>>>              35 RETURN_VALUE        

def string_iterate():
    [item for item in "abc"]

dis.dis(string_iterate)
#>>>   2           0 BUILD_LIST               0
#>>>               3 LOAD_CONST               1 ('abc')
#>>>               6 GET_ITER            
#>>>         >>    7 FOR_ITER                12 (to 22)
#>>>              10 STORE_FAST               0 (item)
#>>>              13 LOAD_FAST                0 (item)
#>>>              16 LIST_APPEND              2
#>>>              19 JUMP_ABSOLUTE            7
#>>>         >>   22 POP_TOP             
#>>>              23 LOAD_CONST               0 (None)
#>>>              26 RETURN_VALUE

Странно то, что у нас то же самое строение списка, но для этого все еще быстрее. Python 2 действует странно быстро.

Уберем осмысления и вернемся снова. Это необходимо _ =для предотвращения его оптимизации.

>>> python3 -m timeit '_ = ["a", "b", "c"]'
10000000 loops, best of 3: 0.0707 usec per loop

>>> python3 -m timeit '_ = "abc"'
100000000 loops, best of 3: 0.0171 usec per loop

Мы видим, что инициализация недостаточно значима, чтобы учесть разницу между версиями (эти числа маленькие)! Таким образом, мы можем сделать вывод, что Python 3 имеет более медленное понимание. Это имеет смысл, поскольку Python 3 изменил понимание, чтобы иметь более безопасную область видимости.

Что ж, теперь улучшите тест (я просто убираю накладные расходы, которые не являются итерациями). Это удаляет построение итерации, предварительно назначив ее:

>>> python3 -m timeit -s 'iterable = "abc"'           '[x for x in iterable]'
1000000 loops, best of 3: 0.387 usec per loop

>>> python3 -m timeit -s 'iterable = ["a", "b", "c"]' '[x for x in iterable]'
1000000 loops, best of 3: 0.368 usec per loop
>>> python2 -m timeit -s 'iterable = "abc"'           '[x for x in iterable]'
1000000 loops, best of 3: 0.309 usec per loop

>>> python2 -m timeit -s 'iterable = ["a", "b", "c"]' '[x for x in iterable]'
10000000 loops, best of 3: 0.164 usec per loop

Мы можем проверить, являются ли вызовы iterнакладными расходами:

>>> python3 -m timeit -s 'iterable = "abc"'           'iter(iterable)'
10000000 loops, best of 3: 0.099 usec per loop

>>> python3 -m timeit -s 'iterable = ["a", "b", "c"]' 'iter(iterable)'
10000000 loops, best of 3: 0.1 usec per loop
>>> python2 -m timeit -s 'iterable = "abc"'           'iter(iterable)'
10000000 loops, best of 3: 0.0913 usec per loop

>>> python2 -m timeit -s 'iterable = ["a", "b", "c"]' 'iter(iterable)'
10000000 loops, best of 3: 0.0854 usec per loop

Нет, это не так. Разница слишком мала, особенно для Python 3.

Итак, давайте удалим еще больше нежелательных накладных расходов ... сделав все это медленнее! Цель состоит в том, чтобы выполнить более длительную итерацию, чтобы время скрыло накладные расходы.

>>> python3 -m timeit -s 'import random; iterable = "".join(chr(random.randint(0, 127)) for _ in range(100000))' '[x for x in iterable]'
100 loops, best of 3: 3.12 msec per loop

>>> python3 -m timeit -s 'import random; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' '[x for x in iterable]'
100 loops, best of 3: 2.77 msec per loop
>>> python2 -m timeit -s 'import random; iterable = "".join(chr(random.randint(0, 127)) for _ in range(100000))' '[x for x in iterable]'
100 loops, best of 3: 2.32 msec per loop

>>> python2 -m timeit -s 'import random; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' '[x for x in iterable]'
100 loops, best of 3: 2.09 msec per loop

На самом деле это не сильно изменилось , но немного помогло.

Так что удалите понимание. Это не часть вопроса:

>>> python3 -m timeit -s 'import random; iterable = "".join(chr(random.randint(0, 127)) for _ in range(100000))' 'for x in iterable: pass'
1000 loops, best of 3: 1.71 msec per loop

>>> python3 -m timeit -s 'import random; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' 'for x in iterable: pass'
1000 loops, best of 3: 1.36 msec per loop
>>> python2 -m timeit -s 'import random; iterable = "".join(chr(random.randint(0, 127)) for _ in range(100000))' 'for x in iterable: pass'
1000 loops, best of 3: 1.27 msec per loop

>>> python2 -m timeit -s 'import random; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' 'for x in iterable: pass'
1000 loops, best of 3: 935 usec per loop

Это больше походит на это! Мы можем стать еще немного быстрее, используя dequeдля итерации. В принципе то же самое, но быстрее :

>>> python3 -m timeit -s 'import random; from collections import deque; iterable = "".join(chr(random.randint(0, 127)) for _ in range(100000))' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 777 usec per loop

>>> python3 -m timeit -s 'import random; from collections import deque; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 405 usec per loop
>>> python2 -m timeit -s 'import random; from collections import deque; iterable = "".join(chr(random.randint(0, 127)) for _ in range(100000))' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 805 usec per loop

>>> python2 -m timeit -s 'import random; from collections import deque; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 438 usec per loop

Что меня впечатляет, так это то, что Unicode конкурирует со строками байтов. Мы можем проверить это явно, попробовав bytesи unicodeв обоих:

  • bytes

    >>> python3 -m timeit -s 'import random; from collections import deque; iterable = b"".join(chr(random.randint(0, 127)).encode("ascii") for _ in range(100000))' 'deque(iterable, maxlen=0)'                                                                    :(
1000 loops, best of 3: 571 usec per loop

>>> python3 -m timeit -s 'import random; from collections import deque; iterable =         [chr(random.randint(0, 127)).encode("ascii") for _ in range(100000)]' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 394 usec per loop
    >>> python2 -m timeit -s 'import random; from collections import deque; iterable = b"".join(chr(random.randint(0, 127))                 for _ in range(100000))' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 757 usec per loop

>>> python2 -m timeit -s 'import random; from collections import deque; iterable =         [chr(random.randint(0, 127))                 for _ in range(100000)]' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 438 usec per loop

    Здесь вы видите, что Python 3 на самом деле быстрее Python 2.

  • unicode

    >>> python3 -m timeit -s 'import random; from collections import deque; iterable = u"".join(   chr(random.randint(0, 127)) for _ in range(100000))' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 800 usec per loop

>>> python3 -m timeit -s 'import random; from collections import deque; iterable =         [   chr(random.randint(0, 127)) for _ in range(100000)]' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 394 usec per loop
    >>> python2 -m timeit -s 'import random; from collections import deque; iterable = u"".join(unichr(random.randint(0, 127)) for _ in range(100000))' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 1.07 msec per loop

>>> python2 -m timeit -s 'import random; from collections import deque; iterable =         [unichr(random.randint(0, 127)) for _ in range(100000)]' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 469 usec per loop

    Опять же, Python 3 быстрее, хотя этого и следовало ожидать ( strв Python 3 ему уделялось много внимания).

На самом деле это unicode- bytesразница очень небольшая, что впечатляет.

Итак, давайте проанализируем этот случай, насколько мне это удобно и быстро:

>>> python3 -m timeit -s 'import random; from collections import deque; iterable = "".join(chr(random.randint(0, 127)) for _ in range(100000))' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 777 usec per loop

>>> python3 -m timeit -s 'import random; from collections import deque; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' 'deque(iterable, maxlen=0)'
1000 loops, best of 3: 405 usec per loop

Мы действительно можем исключить ответ Тима Питера, за который проголосовали 10 раз!

>>> foo = iterable[123]
>>> iterable[36] is foo
True

Это не новые объекты!

Но стоит упомянуть: индексация затрат . Скорее всего, разница будет в индексации, поэтому удалите итерацию и просто проиндексируйте:

>>> python3 -m timeit -s 'import random; iterable = "".join(chr(random.randint(0, 127)) for _ in range(100000))' 'iterable[123]'
10000000 loops, best of 3: 0.0397 usec per loop

>>> python3 -m timeit -s 'import random; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' 'iterable[123]'
10000000 loops, best of 3: 0.0374 usec per loop

Разница кажется небольшой, но как минимум половина стоимости приходится на накладные расходы:

>>> python3 -m timeit -s 'import random; iterable =        [chr(random.randint(0, 127)) for _ in range(100000)]' 'iterable; 123'
100000000 loops, best of 3: 0.0173 usec per loop

так что разницы в скорости достаточно, чтобы винить ее. Думаю.

Так почему же список индексируется намного быстрее?

Что ж, я вернусь к вам по этому поводу, но я предполагаю, что это связано с проверкой интернированных строк (или кешированных символов, если это отдельный механизм). Это будет менее быстро, чем оптимально. Но я пойду проверю источник (хотя мне неудобно в C ...) :).

Итак, вот источник:

static PyObject *
unicode_getitem(PyObject *self, Py_ssize_t index)
{
    void *data;
    enum PyUnicode_Kind kind;
    Py_UCS4 ch;
    PyObject *res;

    if (!PyUnicode_Check(self) || PyUnicode_READY(self) == -1) {
        PyErr_BadArgument();
        return NULL;
    }
    if (index < 0 || index >= PyUnicode_GET_LENGTH(self)) {
        PyErr_SetString(PyExc_IndexError, "string index out of range");
        return NULL;
    }
    kind = PyUnicode_KIND(self);
    data = PyUnicode_DATA(self);
    ch = PyUnicode_READ(kind, data, index);
    if (ch < 256)
        return get_latin1_char(ch);

    res = PyUnicode_New(1, ch);
    if (res == NULL)
        return NULL;
    kind = PyUnicode_KIND(res);
    data = PyUnicode_DATA(res);
    PyUnicode_WRITE(kind, data, 0, ch);
    assert(_PyUnicode_CheckConsistency(res, 1));
    return res;
}

Идя сверху, у нас будет несколько проверок. Это скучно. Затем несколько заданий, которые тоже должны быть скучными. Первая интересная строчка:

ch = PyUnicode_READ(kind, data, index);

но мы надеемся, что это будет быстро, поскольку мы читаем из непрерывного массива C, индексируя его. Результат chбудет меньше 256, поэтому мы вернем кэшированный символ в формате get_latin1_char(ch).

Так что бежим (сбросив первые чеки)

kind = PyUnicode_KIND(self);
data = PyUnicode_DATA(self);
ch = PyUnicode_READ(kind, data, index);
return get_latin1_char(ch);

куда

#define PyUnicode_KIND(op) \
    (assert(PyUnicode_Check(op)), \
     assert(PyUnicode_IS_READY(op)),            \
     ((PyASCIIObject *)(op))->state.kind)

(что скучно, потому что утверждения игнорируются при отладке [так что я могу проверить, что они быстрые] и ((PyASCIIObject *)(op))->state.kind)(я думаю) косвенное обращение и приведение на уровне C);

#define PyUnicode_DATA(op) \
    (assert(PyUnicode_Check(op)), \
     PyUnicode_IS_COMPACT(op) ? _PyUnicode_COMPACT_DATA(op) :   \
     _PyUnicode_NONCOMPACT_DATA(op))

(что тоже скучно по тем же причинам, если предположить, что все макросы ( Something_CAPITALIZED) быстрые),

#define PyUnicode_READ(kind, data, index) \
    ((Py_UCS4) \
    ((kind) == PyUnicode_1BYTE_KIND ? \
        ((const Py_UCS1 *)(data))[(index)] : \
        ((kind) == PyUnicode_2BYTE_KIND ? \
            ((const Py_UCS2 *)(data))[(index)] : \
            ((const Py_UCS4 *)(data))[(index)] \
        ) \
    ))

(который включает индексы, но на самом деле совсем не медленный) и

static PyObject*
get_latin1_char(unsigned char ch)
{
    PyObject *unicode = unicode_latin1[ch];
    if (!unicode) {
        unicode = PyUnicode_New(1, ch);
        if (!unicode)
            return NULL;
        PyUnicode_1BYTE_DATA(unicode)[0] = ch;
        assert(_PyUnicode_CheckConsistency(unicode, 1));
        unicode_latin1[ch] = unicode;
    }
    Py_INCREF(unicode);
    return unicode;
}

Что подтверждает мое подозрение, что:

  • Это кешируется:

    PyObject *unicode = unicode_latin1[ch];

  • Это должно быть быстро. if (!unicode)Не запускается, так что буквально означающего в данном случае

    PyObject *unicode = unicode_latin1[ch];
Py_INCREF(unicode);
return unicode;

Честно говоря, после тестирования быстроты asserts (отключив их [я думаю, что это работает с утверждениями уровня C ...]), единственными правдоподобно медленными частями являются:

PyUnicode_IS_COMPACT(op)
_PyUnicode_COMPACT_DATA(op)
_PyUnicode_NONCOMPACT_DATA(op)

Которые:

#define PyUnicode_IS_COMPACT(op) \
    (((PyASCIIObject*)(op))->state.compact)

(быстро, как и раньше),

#define _PyUnicode_COMPACT_DATA(op)                     \
    (PyUnicode_IS_ASCII(op) ?                   \
     ((void*)((PyASCIIObject*)(op) + 1)) :              \
     ((void*)((PyCompactUnicodeObject*)(op) + 1)))

(быстро, если макрос IS_ASCIIбыстрый), и

#define _PyUnicode_NONCOMPACT_DATA(op)                  \
    (assert(((PyUnicodeObject*)(op))->data.any),        \
     ((((PyUnicodeObject *)(op))->data.any)))

(также быстро, поскольку это утверждение плюс косвенное обращение плюс приведение).

Итак, мы спустились (в кроличью нору) к:

PyUnicode_IS_ASCII

который

#define PyUnicode_IS_ASCII(op)                   \
    (assert(PyUnicode_Check(op)),                \
     assert(PyUnicode_IS_READY(op)),             \
     ((PyASCIIObject*)op)->state.ascii)

Хм ... это тоже кажется быстрым ...

Ну да ладно, но давайте сравним PyList_GetItem. (Да, спасибо Тиму Петерсу за то, что он дал мне больше работы: P.)

PyObject *
PyList_GetItem(PyObject *op, Py_ssize_t i)
{
    if (!PyList_Check(op)) {
        PyErr_BadInternalCall();
        return NULL;
    }
    if (i < 0 || i >= Py_SIZE(op)) {
        if (indexerr == NULL) {
            indexerr = PyUnicode_FromString(
                "list index out of range");
            if (indexerr == NULL)
                return NULL;
        }
        PyErr_SetObject(PyExc_IndexError, indexerr);
        return NULL;
    }
    return ((PyListObject *)op) -> ob_item[i];
}

Мы видим, что в случае отсутствия ошибок это просто запускается:

PyList_Check(op)
Py_SIZE(op)
((PyListObject *)op) -> ob_item[i]

Где PyList_Checkнаходится

#define PyList_Check(op) \
     PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_LIST_SUBCLASS)

( TABS! TABS !!! ) ( issue21587 ) Это было исправлено и объединено за 5 минут . Вроде ... да. Черт. Они посрамили Скита.

#define Py_SIZE(ob)             (((PyVarObject*)(ob))->ob_size)
#define PyType_FastSubclass(t,f)  PyType_HasFeature(t,f)
#ifdef Py_LIMITED_API
#define PyType_HasFeature(t,f)  ((PyType_GetFlags(t) & (f)) != 0)
#else
#define PyType_HasFeature(t,f)  (((t)->tp_flags & (f)) != 0)
#endif

Так что обычно это действительно тривиально (два косвенных обращения и пара логических проверок), если только он не включен Py_LIMITED_API, и в этом случае ... ???

Затем идет индексация и cast ( ((PyListObject *)op) -> ob_item[i]), и все готово.

Так что проверок списков определенно меньше , и небольшие различия в скорости определенно подразумевают, что это может быть актуально.

Я думаю, что в целом (->)для Unicode просто больше проверки типов и косвенного обращения. Кажется, я упустил момент, но что ?

Veedrac
источник
17
Вы представляете код как требующий пояснений; вы даже представляете отрывки как выводы. К сожалению для меня, я не могу этого понять. Я не говорю, что ваш подход к выяснению того, что не так, не является надежным, но было бы неплохо, если бы ему было легче следовать.
PascalVKooten
2
Я пытался улучшить его, но не знаю, как сделать его более понятным. Обратите внимание, что я не пишу C, поэтому это высокоуровневый анализ кода, и важны только общие концепции.
Veedrac
@Nit Я добавил. Скажите мне, если этого не хватает. К сожалению, это также подчеркивает, что я на самом деле не знаю ответа (* вздох *).
Veedrac
3
Я дам это на следующий день, прежде чем приму ваш ответ (я бы хотел увидеть что-то более конкретное), но спасибо за очень интересный и хорошо проработанный ответ.
Санджай Варма
4
Обратите внимание, что вы стреляете по движущейся цели ;-) Эта реализация отличается не только между Python 2 и Python 3, но и между разными версиями. Например, в текущем стволе разработки get_latin1_char()трюк больше не существует unicode_getitem(), а находится на нижнем уровне unicode_char. Так что теперь есть другой уровень вызова функции - или нет (в зависимости от компилятора и используемых флагов оптимизации). На этом уровне детализации просто нет надежных ответов ;-)
Тим Питерс
31

Когда вы перебираете большинство объектов-контейнеров (списки, кортежи, диктовки, ...), итератор доставляет объекты в контейнер.

Но когда вы перебираете строку, новый объект должен быть создан для каждого доставленного символа - строка не является «контейнером» в том же смысле, что список является контейнером. Отдельные символы в строке не существуют как отдельные объекты до того, как итерация создаст эти объекты.

Тим Питерс
источник
3
На самом деле я не думаю, что это правда. Вы можете проверить с is. Это звучит хорошо, но я действительно не думаю , что это может быть.
Veedrac
Взгляните на ответ @Veedrac.
Christian
3
stringobject.cпоказывает, что __getitem__для строк просто извлекает результат из таблицы сохраненных 1-символьных строк, поэтому затраты на выделение для них возникают только один раз.
user2357112 поддерживает Монику
10
@ user2357112, да, для простых строк в Python 2 это жизненно важный момент. В Python 3 все строки «официально» являются Unicode, и здесь задействовано гораздо больше деталей (см. Ответ Veedrac). Например, в Python 3, after s = chr(256), s is chr(256)возвращается False- недостаточно знать только тип, потому что существует множество особых случаев, запускаемых по значениям данных .
Тим Питерс
1

Вы можете понести накладные расходы на создание итератора для строки. В то время как массив уже содержит итератор при создании экземпляра.

РЕДАКТИРОВАТЬ:

>>> timeit("[x for x in ['a','b','c']]")
0.3818681240081787
>>> timeit("[x for x in 'abc']")
0.3732869625091553

Это было запущено с использованием 2.7, но на моем MacBook Pro i7. Это могло быть результатом разницы в конфигурации системы.

Роберт Чамли
источник
Даже при использовании простых итераторов строка все равно значительно медленнее. timeit ("[x вместо x в нем]", "it = iter ('abc')") = 0,34543599384033535; timeit ("[x вместо x в нем]", "it = iter (list ('abc'))") = 0,2791691380446508
Санджай Варма,