An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-help/attachments/20120221/253d41f1/attachment.pl>
Huge difference btw system time and elapsed time
6 messages · R. Michael Weylandt, Martin Maechler, Brian Ripley +1 more
The time relationships aren't strictly linear between any of the three measures, but *very generally* I've interpreted them as something like: User: stuff you do (i.e., doing all the commands) System: stuff at the OS level (memory allocations and whatnot) Elapsed: Clock time None is a great measure in isolation, but the system time is not the worrisome one here: it looks like your script takes about a day and a half to run....that might be ok (and perhaps unavoidable) but it looks like there might be value in trying to squeeze some speed out of your script. A simple thing like byte-compiling that gives 2x speedup would be huge here. Michael
On Tue, Feb 21, 2012 at 10:06 PM, Libo Sun <libosun at rams.colostate.edu> wrote:
Hi all, I got this time for my code,
proc.time()-pt
? ? ?user ? ? system ? ?elapsed 132541.743 ? ? ?0.004 132533.526 As you can see, there is huge difference btw elapsed time and system time. Does that mean lots of I/O? Or some bad coding? Thanks, Libo ? ? ? ?[[alternative HTML version deleted]]
______________________________________________ R-help at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-help/attachments/20120221/9c175983/attachment.pl>
"LS" == Libo Sun <libosun at rams.colostate.edu>
on Tue, 21 Feb 2012 21:09:54 -0700 writes:
> Thanks. Shall I sum the user time and system time, which
> roughly equals to the elapsed time?
No. Rather just use the user time,
i.e. proc.time()[[1]]
system.time()[[1]] etc
That's typically good enough [as long as you don't use
internally multithreaded BLAS, or parallelize / distribute your job,
or other things you won't be doing (yet)].
Martin Maechler, ETH Zurich
> I also tried to improve the code by using 'cmpfun(myfunction)' in
> 'compiler' package, however, it doesn't help too much.
> Libo
On Tue, Feb 21, 2012 at 8:11 PM, R. Michael Weylandt < michael.weylandt at gmail.com> wrote:
The time relationships aren't strictly linear between any of the three measures, but *very generally* I've interpreted them as something like: User: stuff you do (i.e., doing all the commands) System: stuff at the OS level (memory allocations and whatnot) Elapsed: Clock time None is a great measure in isolation, but the system time is not the worrisome one here: it looks like your script takes about a day and a half to run....that might be ok (and perhaps unavoidable) but it looks like there might be value in trying to squeeze some speed out of your script. A simple thing like byte-compiling that gives 2x speedup would be huge here. Michael On Tue, Feb 21, 2012 at 10:06 PM, Libo Sun <libosun at rams.colostate.edu> wrote:
Hi all, I got this time for my code,
proc.time()-pt
user system elapsed 132541.743 0.004 132533.526 As you can see, there is huge difference btw elapsed time and system
time.
Does that mean lots of I/O? Or some bad coding? Thanks, Libo
On 22/02/2012 07:53, Martin Maechler wrote:
"LS" == Libo Sun<libosun at rams.colostate.edu>
on Tue, 21 Feb 2012 21:09:54 -0700 writes:
> Thanks. Shall I sum the user time and system time, which
> roughly equals to the elapsed time?
No. Rather just use the user time,
i.e. proc.time()[[1]]
system.time()[[1]] etc
That's typically good enough [as long as you don't use
internally multithreaded BLAS, or parallelize / distribute your job,
or other things you won't be doing (yet)].
I think the original suggestion was better, and e.g. R CMD check reports the sum of user+system as the CPU time. This is platform-dependent, and on some platforms there can be substantial CPU for your process which is accounted as system time. (I've seen it most often on OS X, but not only there.) The other issue is the fourth and fifth entries, time for children, which as Martin says is only for advanced users (and not reported on Windoww).
Martin Maechler, ETH Zurich
> I also tried to improve the code by using 'cmpfun(myfunction)' in
> 'compiler' package, however, it doesn't help too much.
> Libo
On Tue, Feb 21, 2012 at 8:11 PM, R. Michael Weylandt< michael.weylandt at gmail.com> wrote:
The time relationships aren't strictly linear between any of the three measures, but *very generally* I've interpreted them as something like: User: stuff you do (i.e., doing all the commands) System: stuff at the OS level (memory allocations and whatnot) Elapsed: Clock time None is a great measure in isolation, but the system time is not the worrisome one here: it looks like your script takes about a day and a half to run....that might be ok (and perhaps unavoidable) but it looks like there might be value in trying to squeeze some speed out of your script. A simple thing like byte-compiling that gives 2x speedup would be huge here. Michael On Tue, Feb 21, 2012 at 10:06 PM, Libo Sun<libosun at rams.colostate.edu> wrote:
Hi all, I got this time for my code,
proc.time()-pt
user system elapsed 132541.743 0.004 132533.526 As you can see, there is huge difference btw elapsed time and system
time.
Does that mean lots of I/O? Or some bad coding? Thanks, Libo
______________________________________________ R-help at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
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
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-help/attachments/20120222/176ca462/attachment.pl>