Skip to content

efficient code. how to reduce running time?

11 messages · miraceti, Charilaos Skiadas, Brian Ripley +1 more

#
Dear Mira,

I didn't work through your code in detail, but I did notice that you're
doing something that's very inefficient in R -- building up objects
element-by-element, e.g., by indexing beyond their current length. Instead,
you can preallocate the objects and simply replace elements. For example,
create the vector F in your perm.F() as F <- numeric(nperms) rather than as
an empty vector. (BTW, I'd probably not name a variable "F" since this is
usually a synonym for the logical value FALSE.) There's a similar problem in
your handling of maxF, which you build up column-by-column via cbind().
(BTW, is maxF really a matrix?) You also needlessly recompute max(F), never
appear to use MSSid, and end lines with unnecessary semicolons.

I hope that this helps,
 John

--------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario
Canada L8S 4M4
905-525-9140x23604
http://socserv.mcmaster.ca/jfox 
--------------------------------
#
On Jan 21, 2007, at 5:55 PM, miraceti wrote:

            
Have you looked at lapply, sapply, apply and friends?

Haris
#
Dear Haris,

Using lapply() et al. may produce cleaner code, but it won't necessarily
speed up a computation. For example:
[1] 40.53  0.05 40.61    NA    NA
[1] 53.29  0.37 53.94    NA    NA

In cases such as this, I don't even find the code using *apply() easier to
read.

Regards,
 John

--------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario
Canada L8S 4M4
905-525-9140x23604
http://socserv.mcmaster.ca/jfox 
--------------------------------
#
On Jan 21, 2007, at 8:11 PM, John Fox wrote:

            
Interesting, in my system the results are quite different:

 > system.time(for (i in 1:1000) mods[[i]] <- lm(y ~ X[,i]))
[1] 192.035  12.601 797.094   0.000   0.000
 > system.time(mods <- lapply(as.list(X), function(x) lm(y ~ x)))
[1]  59.913   9.918 289.030   0.000   0.000

Regular MacOSX install with ~760MB memory.
Haris
#
Dear Haris,

My timings were on a 3 GHz Pentium 4 system with 1 GB of memory running Win
XP SP2 and R 2.4.1.

I'm no expert on these matters, and I wouldn't have been surprised by
qualitatively different results on different systems, but this difference is
larger than I would have expected. One thing that seems particularly
striking in your results is the large difference between elapsed time and
user CPU time, making me wonder what else was going on when you ran these
examples.

Regards,
 John

--------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario
Canada L8S 4M4
905-525-9140x23604
http://socserv.mcmaster.ca/jfox 
--------------------------------
#
On Mon, 22 Jan 2007, Charilaos Skiadas wrote:

            
But MacOS X is infamous for having rather specific speed problems with its 
malloc, and so gives different timing results from all other platforms.
We are promised a solution in MacOS 10.5.

Both of your machines seem very slow compared to mine:
user  system elapsed
  11.011   0.250  11.311
user  system elapsed
  13.463   0.260  13.812

and that on a 64-bit platform (AMD64 Linux FC5).
#
Dear Brian,
Thanks for the clarification.
As you can see from the specs (in a previous message), my system is quite
old, which probably accounts for at least part of the difference. The ratios
of the user times for my and your system aren't too different though:
[1] 1.314829
[1] 1.222686

Regards,
 John
#
On Jan 22, 2007, at 10:39 AM, John Fox wrote:

            
Yes, indeed there were a lot of other things going on, this is the  
only machine I have and I use it continuously. I'll try to run  
another test tonight when the machine is not in use.
It did seem a very striking difference though.

But am I wrong in thinking that these measurements should be  
independent of what other applications are running at the same time,  
and should measure exactly the time in terms of CPU cycles needed to  
finish this task, regardless of how often the process got to use the  
CPU? I guess I was working under that assumption, which indeed makes  
the above comparison a very unfair one, because there was a lot more  
going on during the first system.time call.

Still, the difference is quite large, which of course could simply  
have to do with the internals of the two commands, coupled with Prof.  
Ripley's comments about malloc in Mac OS X.
Haris