-
-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TTR::EMA and TTR::DEMA Profiling #69
Comments
Thanks for the report! The xts-input version is slower because the One potential solution is to create a |
This makes it easier to call the ema() C function from other C functions, which can help avoid some of the overhead in R function calls. See #69.
Similar to the previous commit, this makes it easier to call ema() from other C functions. See #69.
@ckatsulis The changes on this branch help close the performance gap in my tests. There's also an xts performance branch that contains some other relevant changes to help make this a bit faster. The I would really appreciate if you could update both packages and provide feedback! Here's the data and tests I was running: require(xts)
require(TTR)
require(microbenchmark)
x <- .xts(rnorm(1e7), 1:1e7)
xts.dema <- function(x) {
.xts(DEMA(coredata(x)), .index(x))
}
ttr.dema <- function(x) {
DEMA(x)
}
Rprof(); o1 <- xts.dema(x); Rprof(NULL); summaryRprof()
Rprof(); o2 <- ttr.dema(x); Rprof(NULL); summaryRprof()
all.equal(drop(coredata(o1)), drop(coredata(o2)))
microbenchmark(xts.dema(x), ttr.dema(x), times = 5)
# Unit: milliseconds
# expr min lq mean median uq max neval cld
# xts.dema(x) 386.1508 413.3212 416.1767 425.5015 426.4050 429.5053 5 a
# ttr.dema(x) 456.2319 487.6094 493.3008 495.4675 509.4217 517.7736 5 b |
Thanks for the update!
…On Mon, Sep 17, 2018 at 12:28 PM Joshua Ulrich ***@***.***> wrote:
Closed #69 <#69> via 25aaf31
<25aaf31>
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#69 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHKwqhwmrL8zGR0AiGpl_FiAaHhgkKj6ks5ub9u3gaJpZM4UyKjG>
.
|
This uses many of the same checks, in the same order, as the ema() C function. That makes it easier and safer to call zlema() from other C functions. This also fixes the issue flagged by clang-UBSAN: We approximated 'n' using 'ratio', but it was possible that ratio = 0. There was a check for ratio > 0 later in the function, but that didn't prevent the possibility of division by 0. Thanks to Prof Ripley for the report. See #100, see #69.
On a quick trial of supplying data to TTR as an
xts
object and then ascoredata
and recasting asxts
, I was able to achieve performance improvements on the order of 60%. Are you able to explain why this is the case, or could you potential modify the call so that it does this naturally?Pass as
coredata
and recast asxts
with.xts
and.index
:1220ms
Pass as original
xts
object:2760ms
The text was updated successfully, but these errors were encountered: