Каква е причината data.table
да е почти 6 пъти по-бавен от xts
при актуализиране (=rbind) на нови редове?
library(quantmod); library(xts); library(data.table)
XTS = getSymbols("AAPL", from="2000-01-01", env = NULL)
# make corresponding `data.table`:
DT <- as.data.table(as.data.frame(XTS))
DT[, Date:=index(XTS)]
setkey(DT,Date)
setcolorder(DT,c("Date",names(XTS)))
# Note: rerun the above before running each test.
system.time(for(i in 1:10) XTS = rbind(XTS, XTS)) # reindexing is automatic
# user system elapsed
# 0.15 0.03 0.47
system.time(for(i in 1:10) DT = setkey(rbind(DT, DT), Date)) # need to manually reset key
# user system elapsed
# 0.64 0.02 2.30
system.time(for(i in 1:10) DT = setkey(rbindlist(list(DT, DT)), Date)) # ditto
# user system elapsed
# 0.60 0.02 2.20
data.table
(за разлика от xts) дори ще изчерпи разпределението на паметта за i>15 на моя компютър.
Обичайният случай на използване при програмиране е, когато изпълнявате времева симулация и искате да съберете междинни измервания в таблица с резултати, която по-късно искате да обобщите.
blotter
? - person Arun   schedule 10.10.2014quantmod
вместоblotter
- това е само за бързо получаване на данни чрезquantmod::getSymbols
. Редактирах въпроса. - person Daniel Krizian   schedule 10.10.2014rbind.xts
е имплементирано в C и ако повторното индексиране се извършва в същата стъпка, то го прави по-ефективно. В DT първо трябва да обвържем, след това да го пренаредим. Бих се опитал да избегна използването му по този начин. Трябва ли да актуализирате по този начин? - person Arun   schedule 10.10.2014rbindlist
трябва да приложи допълнителен аргументkey
, за да върне резултатите вече в сортирания ред. Не съм сигурен как иначе можете да получите същата производителност като xts::rbind - person Arun   schedule 10.10.2014