Tips on tuning DROrthoForest - is its extreme slowness during evaluation expected?

[EgorKraevTransferwise]

Can you please provide some tips on tuning DROrthoForest? From its description it sounds like it would be especially useful on larger datasets due to a local component to the fit, but its performance (in terms of speed) when I tried that is terrible.

I fit it on a dataset with 100K data points and some 600 variables (most of them one-hot-encoded categoricals), and the fit itself is fast enough (about 20 mins), but evaluating the model on that same dataset has so far run 48 hours and shows no signs of completing.

Some tests show that the max_depth and n_trees parameters have almost no effect on speed of evaluation.

First of all, is this intended behavior? It seems weird that it takes orders of magnitude longer to evaluate a forest-style model than to fit it.

Secondly, how can I tweak it so the model becomes usable on datasets of one-two million rows?

Thanks a lot!

fitting backdoor.econml.orf.DROrthoForest {'init_params': {'propensity_model': DummyClassifier(), 'model_Y': Ridge(alpha=0.01), 'n_jobs': 15, 'max_depth': 10, 'n_trees': 500, 'min_leaf_size': 1258, 'backend': 'threading'}, 'fit_params': {}}
[Parallel(n_jobs=15)]: Using backend ThreadingBackend with 15 concurrent workers.
[Parallel(n_jobs=15)]: Done   2 tasks      | elapsed:   19.0s
[Parallel(n_jobs=15)]: Done  98 tasks      | elapsed:  2.2min
[Parallel(n_jobs=15)]: Done 258 tasks      | elapsed:  5.5min
[Parallel(n_jobs=15)]: Done 500 out of 500 | elapsed: 10.4min finished
[Parallel(n_jobs=15)]: Using backend ThreadingBackend with 15 concurrent workers.
[Parallel(n_jobs=15)]: Done   2 tasks      | elapsed:   18.6s
[Parallel(n_jobs=15)]: Done  98 tasks      | elapsed:  2.1min
[Parallel(n_jobs=15)]: Done 258 tasks      | elapsed:  5.5min
[Parallel(n_jobs=15)]: Done 500 out of 500 | elapsed: 10.4min finished
[Parallel(n_jobs=15)]: Using backend ThreadingBackend with 15 concurrent workers.
[Parallel(n_jobs=15)]: Done   2 tasks      | elapsed:  1.3min
[Parallel(n_jobs=15)]: Done  98 tasks      | elapsed:  7.6min
[Parallel(n_jobs=15)]: Done 258 tasks      | elapsed: 18.4min
[Parallel(n_jobs=15)]: Done 482 tasks      | elapsed: 34.7min
[Parallel(n_jobs=15)]: Done 770 tasks      | elapsed: 55.1min
[Parallel(n_jobs=15)]: Done 1122 tasks      | elapsed: 79.9min
[Parallel(n_jobs=15)]: Done 1538 tasks      | elapsed: 109.3min
[Parallel(n_jobs=15)]: Done 2018 tasks      | elapsed: 142.5min
[Parallel(n_jobs=15)]: Done 2562 tasks      | elapsed: 181.0min
[Parallel(n_jobs=15)]: Done 3170 tasks      | elapsed: 223.2min
[Parallel(n_jobs=15)]: Done 3842 tasks      | elapsed: 271.5min
[Parallel(n_jobs=15)]: Done 4578 tasks      | elapsed: 323.2min
[Parallel(n_jobs=15)]: Done 5378 tasks      | elapsed: 379.1min
[Parallel(n_jobs=15)]: Done 6242 tasks      | elapsed: 440.0min
...

PS Others seem to be experiencing this as well.

[CG-ChenGang]

I experienced very, very long training and evaluating time on the DMLOrthoForest, but DROrthoForest worked just fine in my case. My dataset shape was just 10k * 4. It took me 25-30min to train on a 4-core cpu, and another haif an hour to calculate the effects. I validated the time it used on my two computers, google colab and kaggle. In contrast, CausalForest just used 1 or 2 seconds. Will appreciate it if someone can share some knowledge about OrthoForest's speed.

[Sergio666zxy]

Try using the subsample_ratio command to reduce the sample size?