[R] how to run R as a daemon
Prof Brian Ripley
ripley at stats.ox.ac.uk
Mon May 19 16:43:22 CEST 2003
On Mon, 19 May 2003, Laurent Faisnel wrote:
> Prof Brian Ripley wrote:
>
> >On Mon, 19 May 2003, Laurent Faisnel wrote:
> >
> >
> >
> >>I just visited the link you gave me. One of the problems that could
> >>occur using NuSOAP is that I do not intend using Python. Thanks anyway.
> >>I would also like to ask more precise questions :
> >>
> >>
> >
> >`more precise'? At least some of the inefficiencies are emerging, but I
> >still have little picture of what you are actually trying to do. It ought
> >to be possible to run a new R session in a well under a second (on a 1+GHz
> >machine):
> >
> >gannet% time env R_DEFAULT_PACKAGES=NULL R --vanilla --slave < /dev/null
> >0.203u 0.039s 0:00.27 85.1% 0+0k 0+0io 1220pf+0w
> >
>
> I don't understand how you made this test. What does "gannet%" mean?
A totally standard Unix prompt: machine_name% is the default prompt in
csh.
> Anyway, when I launch R with these options (--vanilla and --slave), it
> is fast enough.
>
> >
> >for example (on a dual Athlon 2600, R 1.7.0).
> >
> >
> >
> >>- is it possible to run R as a standalone service, which runs in
> >>background indefinitely, waiting for instructions ?
> >>
> >>
> >
> >It is, but waiting for instructions from one place (stdin or on a socket).
> >
> This is a good piece of news. But how ?
>
> >There is some danger of different jobs sent leaving things behind that
> >will cause interactions.
> >
> I 'll make some tests about possible interactions if I successfully
> launch R in such a mode.
>
> >>This would be a
> >>great improvement for me, since each time it is launched R has to
> >>re-load a (constant) matrix generated thanks to a database connection
> >>(takes a very long while)
> >>
> >>
> >
> >You could just save and then load that matrix in your .RData
> >
> >
> Seems to be a good idea. I'm not used to edit my .RData but sure it
> would be an improvement. I had not even thought about it.
>
> >>- my R script is object-oriented; I define classes and methods, but I'm
> >>not so sure about how methods should be declared; I usually write
> >>something like :
> >>
> >>mymethod <- function(.Object) UseMethod("mymethod",.Object);
> >>
> >>setMethod("mymethod","myclass",
> >> function(.Object)
> >> {
> >> # instructions
> >> return(.Object);
> >> }
> >> );
> >>
> >>Perhaps is this not the best way to write methods ? Could this explain
> >>the following fact : when I run the script, R spends about 1/3 of its
> >>thinking time creating the generic functions linked with my methods.
> >>Isn't this wasted time ? The same script may be executed many times
> >>consecutively by different users, and each time R has to re-define the
> >>generic functions ! (are always the same)
> >>
> >>
> >
> >Yes, but it is your usage that is the problem. You are mixing S3 and S4
> >methods (where did you copy an example like that from?). You should
> >dump your scripts if you use S4 methods (which I don't think you should be
> >doing in such simple examples, nor if you care about speed): see the
> >examples of S4-using packages on CRAN (e.g. DBI, SparseM).
> >
> >
> I clearly prefer using S3 classes & methods. I knew S4 classes would
> cause slowness problems. But I did not find a clear documentation about
> differences between S3 and S4. Neither did I find detailed tutorials
> about R programming. Which part of my code structure is S3-like and
> which one is S4-like ? Is the above-mentionned problem S4 classes' fault
> ? You mean with clean S3 scripts I would have none of these drawbacks ?
There's a book called `S Programming' that has all this crystal clear, and
it is in the FAQ!
> >Also consider upgrading to R 1.7.0 and setting R_DEFAULT_PACKAGES to what
> >you actually need (and omit methods if you don't need it)
> >
> >
> >
> I won't use R 1.7.0 for the time. First everything has to work fine with
> R 1.6.2. I think I have few things in R_DEFAULT_PACKAGES, and I cannot
> omit methods because I use them all !
That's the `methods' package, only needed for S4 methods.
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-help
mailing list