Похоже, что Уэс, возможно, обнаружил известную проблему в data.table, когда число уникальных строк ( уровней ) велико: 10000.
Показывает ли Rprof() большую частьвремя, проведенное в звонке sortedmatch(levels(i[[lc]]), levels(x[[rc]])?Это на самом деле не само объединение (алгоритм), а предварительный шаг.
Недавние усилия были направлены на то, чтобы разрешить символьные столбцы в ключах, что должно решить эту проблему путем более тесной интеграции с собственным глобальным строковым хешем RТаблица.Некоторые результаты тестов уже сообщаются test.data.table(), но этот код еще не подключен для замены уровней на совпадение уровней.
Панды сливаются быстрее, чем data.table для обычных целочисленных столбцов?Это должен быть способ изолировать сам алгоритм от проблем фактора.
Кроме того, data.table имеет в виду слияние временных рядов .Два аспекта этого: i) многостолбцовые упорядоченные ключи, такие как (id, datetime) ii) быстрое преобладающее соединение (roll=TRUE), то есть последнее перенесенное наблюдение.
Мне понадобитсянемного времени для подтверждения, так как это первое, что я видел в сравнении с data.table в представленном виде.
ОБНОВЛЕНИЕ из data.table v1.8.0, выпущенного в июле 2012 года
- Внутренняя функция sortedmatch () удалена и заменена на chmatch () при сопоставлении уровней i с уровнями x для столбцов типа 'factor'.Этот предварительный шаг вызывал (известное) значительное замедление, когда число уровней столбца факторов было большим (например,> 10000).Усиление в тестах объединения четырех таких столбцов, как продемонстрировал Уэс МакКинни (автор пакета Python Pandas).Например, соответствие миллиону строк, из которых 600 000 уникальны, теперь уменьшено с 16 до 0,5.
также в этом выпуске было:
столбцы символов теперь разрешены в ключах и предпочтительнее фактораdata.table () и setkey () больше не приводят символ к фактору.Факторы все еще поддерживаются.Реализует FR # 1493, FR # 1224 и (частично) FR # 951.
Новые функции chmatch () и% chin%, более быстрые версии match () и% в% для символавекторы.Используется внутренний строковый кеш R (хеш-таблица не создается).Они примерно в 4 раза быстрее, чем match () в примере в? Chmatch.
По состоянию на сентябрь 2013 года data.table на CRAN v1.8.10, а мы работаем на v1.9,0. NEWS обновляется в режиме реального времени.
Но, как я писал ранее, выше:
data.table имеет временные ряды объединяются в виду.Два аспекта: i) многостолбцовые упорядоченные ключи, такие как (id, datetime) ii) быстрое преобладающее соединение (roll=TRUE), то есть последнее перенесенное наблюдение.
ИтакPandas equi соединение двух столбцов символов, вероятно, все еще быстрее, чем data.table.Так как он звучит так, как будто он объединяет две колонки.data.table не хэширует ключ, потому что имеет в виду преобладающие упорядоченные объединения.«Ключ» в data.table - это буквально просто порядок сортировки (аналогично кластерному индексу в SQL; т. Е. Так упорядочиваются данные в оперативной памяти).В список следует добавить дополнительные ключи, например.
В итоге, явная разница в скорости, выделенная этим конкретным двухсимвольным тестом с более чем 10000 уникальными строками, не должна быть такой плохой, посколькуизвестная проблема была исправлена.