Hi,
meik michalke schrieb:
> as one result of our ongoing workshop, a participant argued that while rkward
> provides a really comfortable interface for R development, it does consume
> valuable processing ressources to an extent that when it comes to actual
> huge/complex calculations, he wouldn't consider doing it with rkward.
>
> i guess it's the implementation of the R console and the way it communicates
> with the backend that produces the noticeable overhead. is there something we
> could do about this? perhaps making it possible to clone the workspace as a
> new "native" R session if you need to boost performance? or the possibility
> to
> switch off rkward's R console wrapper?
ATM, I am aware of only one use case, where performance in RKWard is
*seriously* degraded when compared to plain R. This is when running a
long loop in .GlobalEnv like this:
i <- 1
for (i in 1:100000) { i+i }
Note when you now do
rm (i)
for (i in 1:100000) { i+i }
the loop should finish much faster, and performance should be roughly
back on par with plain R. The reason is that RKWard uses "active
bindings" to keep track of changes in R objects. In the first example, i
is replaced with an active binding, and slows down each access to i,
considerably. In the second example, the "i" used in the loop is just a
regular R object.
I assume, this is the performance problem that you are seeing.
In fact, that is pretty embarassing, and needs to be fixed, sooner or
later. Here's the reminding ticket for the issue:
https://sourceforge.net/tracker/?func=detail&aid=1810061&group_id=50231&atid=459010
. By now I have a new idea on how to approach this, which should result
in virtually no performance loss at this point (without using active
bindings).
It is possible to work around this, though, by using local variables. E.g.
i <- 1
local({
for (i in 1:100000) { i+i }
})
Here, a local object "i" will be used, which RKWard will not try to
track (and the global object "i" will remain untouched). Or - perhaps
more realistically - place all your code into functions. After all,
that's generally a good idea in the first place.
Ok, there are a few other cases, where there is overhead. For instance,
loading libraries/packages is typically a good bit slower in RKWard, but
then, that is mostly a one-time thing per session. Also, RKWard is
considerably slower, when there is a huge amount of output. And there's
an unavoidable memory-overhead, of course, simply for having RKWard
loaded. But I guess none of these is what you are talking about, right?
Regards
Thomas
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel
