[R] randomForest speed improvements

[Liaw, Andy]

If you have multiple cores, one "poor man's solution" is to run separate
forests in different R sessions, save the RF objects, load them into the
same session and combine() them.  You can do this less clumsily if you
use things like Rmpi or other distributed computing packages.

Another consideration is to increase nodesize (which reduces the sizes
of trees).  The problem with numeric predictors for tree-based
algorithms is that the number of computations to find the best splitting
point increases by that much _at each node_.  Some algorithms try to
save on this by using only certain quantiles.  The current RF code
doesn't do this.

Andy

 

> -----Original Message-----
> From: r-help-bounces at r-project.org 
> [mailto:r-help-bounces at r-project.org] On Behalf Of apresley
> Sent: Monday, January 03, 2011 6:28 PM
> To: r-help at r-project.org
> Subject: Re: [R] randomForest speed improvements
> 
> 
> I haven't tried changing the mtry or ntree at all ... though 
> I suppose with
> only 6 variables, and tens-of-thousands of rows, we can 
> probably do less
> than 500 tree's (the default?).
> 
> Although tossing the forest does speed things up a bit, seems 
> to be about 15
> - 20% faster in some cases, I need to keep the forest to do 
> the prediction,
> otherwise, it complains that there is no forest component in 
> the object.
> 
> --
> Anthony
> -- 
> View this message in context: 
> http://r.789695.n4.nabble.com/randomForest-speed-improvements-
> tp3172523p3172834.html
> Sent from the R help mailing list archive at Nabble.com.
> 
> ______________________________________________
> 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.
> 
Notice:  This e-mail message, together with any attachme...{{dropped:11}}