Почему pandas сливается в python быстрее, чем data.table сливается в R?

Ответ 1

Похоже, что Уэс, возможно, обнаружил известную проблему в data.table, когда число уникальных строк (уровней) велико: 10 000.

Знает ли Rprof() большую часть времени, затраченного на вызов sortedmatch(levels(i[[lc]]), levels(x[[rc]])? Это не само соединение (алгоритм), а предварительный шаг.

Недавние усилия по предоставлению столбцов символов в ключах, которые должны решить эту проблему, более тесно связаны с собственной глобальной хэш-таблицей R. Некоторые результаты тестов уже сообщены test.data.table(), но этот код еще не подключен, чтобы заменить уровни на уровни.

Являются ли pandas более быстрыми, чем data.table для регулярных целых столбцов? Это должно быть способом изолировать сам алгоритм от факторов.

Кроме того, data.table имеет временные ряды. Два аспекта этого: i) упорядоченные несколько столбцов ключей, такие как (id, datetime) ii) быстрое преобладание соединения (roll=TRUE). Последнее наблюдение a.k.a. переносится вперед.

Мне нужно некоторое время для подтверждения, поскольку это первое, что я видел в сравнении с data.table, как представлено.

ОБНОВЛЕНИЕ from data.table v1.8.0 выпущено в июле 2012 г.

• Внутренняя функция sortedmatch() удалена и заменена на chmatch()      при сопоставлении уровней я с уровнями x для столбцов типа "фактор". Эта      предварительный шаг вызывал (известный) значительный спад, когда число      уровней факторного столбца были большими (например, > 10000). Обострение в      тесты объединения четырех таких столбцов, о чем свидетельствует Уэс МакКинни      (автор пакета Python Pandas). Соответствие 1 млн. Строк, из которых      из которых 600 000 уникальны, теперь сокращается с 16 до 0,5 с, например.

также в том, что релиз был:

• столбцы символов теперь разрешены в ключах и являются предпочтительными фактор. data.table() и setkey() больше не принуждают персонажа к фактор. Факторы по-прежнему поддерживаются. Реализует FR # 1493, FR # 1224 и (частично) FR # 951.

• Новые функции chmatch() и% chin%, более быстрые версии match() и% в% для символьных векторов. R внутренний строковый кеш (нет хеш-таблицы). Они примерно в 4 раза быстрее чем match() в примере в? chmatch.

По состоянию на сентябрь 2013 г. data.table v1.8.10 на CRAN, и мы работаем над v1.9.0. NEWS обновляется в прямом эфире.

Но, как я писал изначально, выше:

data.table имеет временные ряды. Два аспекта: i) несколько столбцов упорядоченных ключей, таких как (id, datetime) ii) быстрое преобладание join (roll=TRUE) a.k.a. последнее наблюдение переносится вперед.

Таким образом, объединение pandas equi двух столбцов символов, вероятно, еще быстрее, чем data.table. Так как это звучит, как будто хэширует объединенные две колонки. data.table не hash ключ, потому что он имеет преобладающее упорядоченное объединение в виду. "Ключ" в data.table - это буквально просто порядок сортировки (аналогичный кластерному индексу в SQL, т.е. То, как данные упорядочиваются в ОЗУ). Например, в список добавляются дополнительные ключи.

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

Ответ 2

Причина pandas быстрее, потому что я придумал лучший алгоритм, который очень тщательно реализован, используя быструю реализацию хэш-таблицы - klib и в C/Cython, чтобы избежать накладных расходов интерпретатора Python для не-векционируемых частей. Алгоритм подробно описан в моей презентации: Взгляд внутрь pandas дизайн и разработка.

Сравнение с data.table на самом деле немного интересно, потому что вся точка R data.table заключается в том, что он содержит предварительно вычисленные индексы для разных столбцов для ускорения операций, таких как выбор и слияние данных. В этом случае (объединение базы данных) pandas 'DataFrame не содержит предварительно вычисленной информации, которая используется для слияния, так сказать, это "холодное" слияние. Если бы я сохранил факторизованные версии ключей соединения, объединение было бы значительно быстрее - поскольку факторизация является самым большим узким местом для этого алгоритма.

Я также должен добавить, что внутренний дизайн pandas 'DataFrame гораздо более поддается этим операциям, чем R data.frame(это всего лишь список массивов внутри).

Ответ 3

Этот вопрос два года, но кажется вероятным местом для людей, чтобы приземлиться, когда они ищут сравнения Pandas и data.table

Поскольку оба из них эволюционировали со временем, я хочу опубликовать относительно более новое сравнение (с 2014 года) здесь для заинтересованных пользователей: https://github.com/Rdatatable/data.table/wiki/Benchmarks-:-Grouping

Было бы интересно узнать, есть ли Уэс и/или Мэтт (которые, кстати, являются создателями Pandas и data.table соответственно и имеют оба комментария выше), есть новости, которые нужно добавить здесь.

- ОБНОВЛЕНИЕ -

Комментарий, отправленный ниже jangorecki, содержит ссылку, которая, по моему мнению, очень полезна: https://github.com/szilard/benchm-databases

На этом графике показаны средние времена операций агрегации и объединения для разных технологий ( ниже = быстрее, последнее обновление обновлено в сентябре 2016 года). Это было действительно для меня.

Возвращаясь к вопросу, R DT key и R DT относятся к ключам с ключами/без ключа R data.table и в этом тесте быстрее, чем Python Pandas (Py pandas).