Pandas groupby.size vs series.value_counts vs collections.Counter с несколькими сериями

На самом деле в zip(df.A.values, df.B.values) есть немного скрытых накладных расходов. Ключ здесь сводится к тому, что массивы numpy хранятся в памяти принципиально другим способом, чем объекты Python.

Массив numpy, такой как np.arange(10), по существу хранится как непрерывный блок памяти, а не как отдельные объекты Python. И наоборот, список Python, такой как list(range(10)), хранится в памяти как указатели на отдельные объекты Python (т.е. целые числа 0-9). Это различие является причиной того, почему массивы numpy меньше в памяти, чем списки эквивалентов Python, и почему вы можете выполнять более быстрые вычисления с массивами numpy.

Итак, поскольку Counter использует zip, связанные кортежи должны быть созданы как объекты Python. Это означает, что Python необходимо извлечь значения кортежа из numpy данных и создать соответствующие объекты Python в памяти. Это связано с заметными накладными расходами, поэтому вы должны быть очень осторожны при объединении чистых функций Python с numpy данными. Базовый пример этой ловушки, которую вы обычно можете увидеть, - это использование встроенного Python sum в массиве numpy: sum(np.arange(10**5)) на самом деле немного медленнее, чем чистый Python sum(range(10**5)), и оба из них, конечно, значительно медленнее, чем np.sum(np.arange(10**5)).

См. это видео для более подробного обсуждения этой темы.

В качестве примера, относящегося к этому вопросу, обратите внимание на следующие моменты времени, сравнивая производительность Counter на заархивированных массивах numpy с соответствующими заархивированными списками Python.

In [2]: a = np.random.randint(10**4, size=10**6)
   ...: b = np.random.randint(10**4, size=10**6)
   ...: a_list = a.tolist()
   ...: b_list = b.tolist()

In [3]: %timeit Counter(zip(a, b))
455 ms ± 4.7 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [4]: %timeit Counter(zip(a_list, b_list))
334 ms ± 4.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Разница между этими двумя временами дает вам разумную оценку накладных расходов, о которых говорилось ранее.

Однако это еще не конец истории. Создание объекта groupby в пандах также связано с некоторыми накладными расходами, по крайней мере, в том, что касается этой проблемы, поскольку есть некоторые метаданные groupby, которые не являются строго необходимыми только для получения size, тогда как Counter делает единственную вещь, которая вам небезразлична. Обычно эти накладные расходы намного меньше, чем накладные расходы, связанные с Counter, но в результате некоторых быстрых экспериментов я обнаружил, что вы действительно можете получить немного лучшую производительность от Counter, когда большинство ваших групп состоит только из отдельных элементов.

Рассмотрим следующие тайминги (используя предложение @ BallpointBen sort=False), которые соответствуют спектру нескольких больших групп <--> многих малых групп:

def grouper(df):
    return df.groupby(['A', 'B'], sort=False).size()

def count(df):
    return Counter(zip(df.A.values, df.B.values))

for m, n in [(10, 10**6), (10**3, 10**6), (10**7, 10**6)]:

    df = pd.DataFrame({'A': np.random.randint(0, m, n),
                       'B': np.random.randint(0, m, n)})

    print(m, n)

    %timeit grouper(df)
    %timeit count(df)

Это дает мне следующую таблицу:

m       grouper   counter
10      62.9 ms    315 ms
10**3    191 ms    535 ms
10**7    514 ms    459 ms

Конечно, любой выигрыш от Counter будет компенсирован обратным преобразованием в Series, если это то, что вы хотите в качестве конечного объекта.