Ответ 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 уникальными строками, теперь не должна быть такой же плохой, поскольку известная проблема исправлена.
