RF 的整体复杂性类似于；如果您想加快计算速度，可以尝试以下方法：$\text{ntree}\cdot\text{mtry}\cdot(\text{# objects})\log( \text{# objects})$

1. 使用randomForest代替party，或者，甚至更好，ranger或者Rborist（虽然两者都还没有经过实战测试）。
2. 不要使用公式，即调用randomForest(predictors,decision)而不是randomForest(decision~.,data=input).
3. 使用do.trace参数实时查看OOB错误；这样你可能会发现你可以降低ntree.
4. 关于因素；RF（和所有树方法）试图找到一个最优的级别子集，从而扫描可能性；为此，这个因子可以为您提供如此多的信息是相当幼稚的——更不用说 randomForest 不会吃掉超过 32 个级别的因子。也许您可以简单地将其视为有序的（因此相当于 RF 的正常数字变量）或将其聚集在某些组中，将这一属性分成几个？$2^\text{(# of levels-1)}$
5. 检查您的计算机是否没有用完 RAM 并且它正在使用交换空间。如果是这样，买一台更大的电脑。
6. 最后，您可以提取一些随机的对象子集并对此进行一些初步实验。

因为 randomForest 是一组独立的推车，这些推车是根据随机的特征子集和记录进行训练的，因此它适合于并行化。combine()randomForest 包中的函数将独立训练的森林拼接在一起。这是一个玩具示例。正如@mpq 的回答所述，您不应使用公式表示法，而应传入变量的数据框/矩阵和结果向量。我无耻地从文档中提取了这些。

library("doMC")
library("randomForest")
data(iris)

registerDoMC(4) #number of cores on the machine
darkAndScaryForest <- foreach(y=seq(10), .combine=combine ) %dopar% {
   set.seed(y) # not really needed
   rf <- randomForest(Species ~ ., iris, ntree=50, norm.votes=FALSE)
}

我将 randomForest 组合函数传递给类似命名的 .combine 参数（它控制循环输出的函数。不利的一面是你没有得到 OOB 错误率或更可悲的变量重要性。

编辑：

重读帖子后，我意识到我对 34+ 因素问题只字未提。一个完全没有经过深思熟虑的答案可能是将它们表示为二进制变量。那是每个因素都被编码为关于其存在/不存在的 0/1 级因素的列。通过对不重要的因素进行一些变量选择并删除它们，您可以防止特征空间变得太大。

我无法谈论 R 中特定算法的速度，但很明显是什么导致了计算时间过长。对于每个分支上的每棵树，CART 都在寻找最佳的二元分割。因此，对于 34 个特征中的每一个，它最关注的是每个变量级别给出的拆分。将树中每个拆分的运行时间乘以树中的分支数，然后将其乘以森林中的树数，运行时间就会很长。谁知道？也许即使有一台快速的计算机，这也可能需要数年才能完成？

我认为加快速度的最佳方法是将一些级别合并在一起，以便每个变量降低到 3 到 5 个级别，而不是多达 300 个。当然，这取决于能够做到这一点而不会失去重要的您数据中的信息。

在那之后，也许你可以看看是否有一些聪明的算法可以加快在单个树的每个节点处分割的搜索时间。可能是在特定的树上，拆分搜索是对前一棵树已经完成的搜索的重复。因此，如果您可以保存先前拆分决策的解决方案并确定您何时重复，那么该策略可能会节省一点计算时间。

我建议几个链接：

1）缩小因子变量的级别数 是一个问题的链接，用于在使用包stackoverflow时处理类似问题。randomForest具体来说，它处理仅使用最频繁出现的级别并将新级别分配给所有其他不太频繁出现的级别。

它的想法来自这里：2009 KDD 杯慢速挑战赛。本次比赛的数据有很多级别的因素，它讨论了他们用来将数据从 50,000 行减少 15,000 列以在 2 核/2GB RAM 笔记本电脑上运行的一些方法。

我的最后一个建议是考虑在高 CPU Amazon EC2 实例上并行运行问题，如上所述。