MithunR

I'll explore the data and post more info here. I'm still looking at the call stack, etc. There are certainly wins to be had by switching the query from using...

@jlowe mentioned this: @revans2 already has a fix/workaround in place in Spark-RAPIDS, to detect queries of the from `instr(...,...) > 0`, to convert them into a call to `strings::contains()`. It...

I have done some exploration of the data in question, and the query. 1. The query has about 25 invocations of `instr`, which amounts to 25 calls to `strings::contains()` per...

I'm working on a block-parallel version of `contains()` that looks a lot like the warp-parallel one. Testing it out now.

As an aside, I should mention that the data distributions I mentioned above can be ignored, for the moment. The sample is not representative of the user's data.

I have a naive block-parallel implementation [here](https://github.com/mythrocks/cudf/blob/block-parallel-contains/cpp/src/strings/search/find.cu#L378). This change switches to block-parallel if the average string length reaches 256 or 512. (I've tried both.) Here are some results from running...

From exploring the customer's data, it appears that the majority of the search input strings are under 256 bytes long, although there are outliers (some being 64K long). The average...

I've generated a local dataset with the search key distributions in much the same way as that of the reported slow case. (This includes the order of if-else clauses, with...

P.S. I think I left the impression that the `string::contains` kernel is "slow", in absolute terms. That isn't accurate. More correctly, the profiles of the Spark tasks indicate that the...

The first approach (processing 1 string/threadblock instead of 1 string/warp) was a bust. At the user's average string size of 144 characters, it appeared that too many threads in the...