While loop in R quantstrat code - how to make it faster? -
in quantstrat package have located 1 of main culprits slowness of applyrule function , wonder if there more efficient write while loop. feedback helpful. experience wrapping part parallel r.
as option apply work instead while? or should re-write part new function such ruleproc , nextindex? dveling on rcpp may streach. , constructive advice appreciated?
while (curindex) { timestamp = dates[curindex] if (istrue(hold) & holdtill < timestamp) { hold = false holdtill = null } types <- sort(factor(names(strategy$rules), levels = c("pre", "risk", "order", "rebalance", "exit", "enter", "entry", "post"))) (type in types) { switch(type, pre = { if (length(strategy$rules[[type]]) >= 1) { ruleproc(strategy$rules$pre, timestamp = timestamp, path.dep = path.dep, mktdata = mktdata, portfolio = portfolio, symbol = symbol, ruletype = type, mktinstr = mktinstr) } }, risk = { if (length(strategy$rules$risk) >= 1) { ruleproc(strategy$rules$risk, timestamp = timestamp, path.dep = path.dep, mktdata = mktdata, portfolio = portfolio, symbol = symbol, ruletype = type, mktinstr = mktinstr) } }, order = { if (length(strategy$rules[[type]]) >= 1) { ruleproc(strategy$rules[[type]], timestamp = timestamp, path.dep = path.dep, mktdata = mktdata, portfolio = portfolio, symbol = symbol, ruletype = type, mktinstr = mktinstr,) } else { if (istrue(path.dep)) { timespan <- paste("::", timestamp, sep = "") } else timespan = null ruleorderproc(portfolio = portfolio, symbol = symbol, mktdata = mktdata, timespan = timespan) } }, rebalance = , exit = , enter = , entry = { if (istrue(hold)) next() if (type == "exit") { if (getposqty(portfolio = portfolio, symbol = symbol, date = timestamp) == 0) next() } if (length(strategy$rules[[type]]) >= 1) { ruleproc(strategy$rules[[type]], timestamp = timestamp, path.dep = path.dep, mktdata = mktdata, portfolio = portfolio, symbol = symbol, ruletype = type, mktinstr = mktinstr) } if (istrue(path.dep) && length(getorders(portfolio = portfolio, symbol = symbol, status = "open", timespan = timestamp, which.i = true))) { } }, post = { if (length(strategy$rules$post) >= 1) { ruleproc(strategy$rules$post, timestamp = timestamp, path.dep = path.dep, mktdata = mktdata, portfolio = portfolio, symbol = symbol, ruletype = type, mktinstr = mktinstr) } }) } if (istrue(path.dep)) curindex <- nextindex(curindex) else curindex = false }
garrett's answer point last major discussion on r-sig-finance list related question discussed.
the applyrules function in quantstrat absolutely of time spent.
the while loop code copied in question path-dependent part of applyrules execution. believe of covered in documentation, i'll briefly review posterity.
we construct dimension reduction index inside applyrules don't have observe every timestamp , check it. take note of specific points in time strategy may reasonably expected act on order book, or orders may reasonably expected filled.
this state-dependent , path-dependent code. idle talk of 'vectorization' doesn't make sense in context. if need know current state of market, order book, , position, , if orders may modified in time-dependent manner other rules, don't see how code can vectorized.
from computer science perspective, state machine. state machines in every language can think of written while loops. isn't negotiable or changeable.
the question asks if use of apply help. apply statements in r implemented loops, no, wouldn't help. parallel apply such mclapply or foreach can't because inside state dependent part of code. evaluating different time points without regard state doesn't make sense. you'll note non-state-dependent parts of quantstrat vectorized wherever possible, , account little of running time.
the comment made john suggests removing loop in ruleproc. loop check each rule associated strategy @ point in time. compute-intensive part of loop do.call call rule function. rest of loop locating , matching arguments these functions, , code profiling, doesn't take time @ all. not make sense use parallel apply here either, since rule functions applied in type order, cancels or risk directives can applied before new entry directives. mathematics has order of operations, or bank has deposit/withdrawal processing order, quantstrat has rule type evaluation order, laid out in documentation.
to speed execution, there 4 main things can done:
- write non-path dependent strategy: supported code, , simple strategies may modeled way. in model write custom rule function calls addtxn directly when think should fills. vectorized function operating on indicators/signals, , should fast.
- preprocess signals:if there fewer places state machine needs evaluate state of order book/rules/portfolio see if needs something, speed increase linear reduction in signals. area users neglect, writing signal functions don't evaluation of when action may required modify positions or order book.
- explicitly parallelize parts of analysis problem: commonly write explicitly parallel wrappers separate out different parameter evaluations or symbol evaluations, see applyparameter example using foreach
- rewrite state machine inside applyrules in c/c++: patches welcome, see link garrett posted additional details.
i can assure strategies can run in fraction of core-minute per symbol per day per core on tick data, if little care taken signal generation functions. running large backtests on laptop not recommended.
Comments
Post a Comment