Я начал верить, что кадры данных не имеют преимуществ перед матрицами, за исключением удобства обозначения.Однако я заметил эту странность при запуске unique на матрицах и фреймах данных: кажется, что он работает быстрее на фрейме данных.
a = matrix(sample(2,10^6,replace = TRUE), ncol = 10)
b = as.data.frame(a)
system.time({
u1 = unique(a)
})
user system elapsed
1.840 0.000 1.846
system.time({
u2 = unique(b)
})
user system elapsed
0.380 0.000 0.379
Результаты синхронизации расходятся еще более существенно по мере увеличения количества строк,Итак, этот вопрос состоит из двух частей:
Почему это медленнее для матрицы?Кажется, быстрее преобразовать в фрейм данных, запустить unique, а затем выполнить обратное преобразование.
Есть ли какая-либо причина не просто обернуть unique в myUnique, что делает преобразования в части №1?
Примечание 1. Учитывая, что матрица является атомарной, кажется, что unique должно быть быстрее для матрицы, а не медленнее.Возможность перебирать непрерывные блоки памяти фиксированного размера, как правило, должна выполняться быстрее, чем запускать отдельные блоки связанных списков (я полагаю, именно так реализованы фреймы данных ...).
Примечание 2. Как продемонстрированоиз-за производительности data.table выполнение unique для фрейма данных или матрицы является сравнительно плохой идеей - см. ответ Мэтью Доула и комментарии относительно относительного времени.Я перенес много объектов в таблицы данных, и эта производительность является еще одной причиной для этого.Таким образом, хотя пользователи должны быть хорошо приспособлены к принятию таблиц данных, по педагогическим / общественным причинам я пока оставлю открытым вопрос о , почему занимает больше времени на матричных объектах.Ответы ниже приведены по адресу , где показывает время, а как еще как мы можем повысить производительность (например, таблицы данных).Ответ на , почему под рукой - код можно найти через unique.data.frame и unique.matrix.:) Английское объяснение того, что он делает и почему всего этого не хватает.