Thomas B

> You don't need to force-push here. All commits will be squashed on merge. Thanks! :) That was just me organizing my work though (I wanted this commit specifically to...

So I've finished my benchmarks and it turns out: - I can see the expected performance improvements of x N_CPUs performance - [The sub-optimal locking](https://github.com/microsoft/LightGBM/pull/2760#issuecomment-1683075872) has no impact - I...

> Each thread has its own copy of `FastConfigHandle` Of `BoosterHandle` but I think that's what you meant. Otherwise yes that's exactly it.

> Let me know if my understanding of API usage is correct or not Your understanding is correct, it seems to be just a matter of definitions that caused our...

> I think with the above-described usage, the API `LGBM_BoosterPredictForMatSingleRowFastInit` is not thread-safe. Feel free to ignore(or delete this message) this if you think this is not problematic or false...

TLDR; All comments resolved. > can you add a test to our C++ test suite showing multiple predictors using the fast API and sharing the booster? That took a while...

@guolinke Static analysis complains that the TODO tag (https://github.com/microsoft/LightGBM/pull/6024#discussion_r1332536566) is not assigned. Who should I assign it to?

> Can you suggest some names that you think are more informative or clearer? Whoops, looks like I forgot this this time. 😅 Thanks, updated message above.

That is true. In that case what you probably want to do is first remap your name to an int key: ```c++ int new_indexes = 0; unordered_map m; auto f...

Same problem here, took a few hours to diagnose that this was the issue. We're also seeing a bunch of "Too many open files" errors coming from the consumer threads,...