I have noticed also that GBRT can be quite slow even for small k.
Since GBRT fits n*k decision trees, by design, it's crucial that the
decision tree code be highly optimized. I did some quick performance
profiling the other day, which showed that the performance bottleneck
was spent in the method
On Mar 25, 2012, at 10:37 AM, Peter Prettenhofer
wrote:
> 2012/3/25 Scott White :
>> I have noticed also that GBRT can be quite slow even for small k.
>> Since GBRT fits n*k decision trees, by design, it's crucial that the
>> decision tree code be highly optimized. I
/25 Scott White :
>> Btw, another thing I think we should add is the ability to monitor the
>> out-of-bag estimates after each iteration and allow the fitting to be
>> terminated early. It's usually hard to guess the right number of
>> iterations required and if one can t
sults that can help speed things up a lot.
cheers,
Scott
On Sun, Mar 25, 2012 at 10:10 AM, Scott White wrote:
> I have noticed also that GBRT can be quite slow even for small k.
> Since GBRT fits n*k decision trees, by design, it's crucial that the
> decision tree code be highly op
