Optimize cudf::make_strings_column for long strings

[davidwendt]

Reference #7571
This improves the performance of the cudf::make_strings_column for long strings. It uses a similar approach from cudf::strings::detail::gather and also use thresholding as in the optimized cudf::strings::replace.
This may not be the right solution for overall optimizing #7571 but may be helpful in other places where long strings are used for created a strings column in libcudf.
This PR also includes a gbenchmark to help measure the performance results of this factory function. The results of the benchmark are that longer strings (~ >64 bytes on average) showed about a 10x improvement. I can post benchmark results here if needed. The character-parallel algorithm was slower for shorter strings so the existing algorithm is used based on the a threshold calculation.
I also added an additional gtest with a mixture of nulls and empty strings to make sure the new algorithm handles these correctly.

[codecov]

Codecov Report

Merging #7576 (6163360) into branch-0.19 (7871e7a) will increase coverage by 0.13%.
The diff coverage is 93.78%.

@@               Coverage Diff               @@
##           branch-0.19    #7576      +/-   ##
===============================================
+ Coverage        81.86%   82.00%   +0.13%     
===============================================
  Files              101      101              
  Lines            16884    16991     +107     
===============================================
+ Hits             13822    13933     +111     
+ Misses            3062     3058       -4     

Impacted Files	Coverage Δ
python/cudf/cudf/core/index.py	92.86% <ø> (ø)
python/cudf/cudf/core/column/numerical.py	94.83% <87.50%> (-0.20%)	⬇️
python/cudf/cudf/core/frame.py	89.00% <89.47%> (-0.02%)	⬇️
python/cudf/cudf/core/column/column.py	87.77% <90.00%> (+0.01%)	⬆️
python/cudf/cudf/core/column/decimal.py	92.75% <90.32%> (-2.12%)	⬇️
python/cudf/cudf/core/dataframe.py	90.45% <95.65%> (-0.01%)	⬇️
python/cudf/cudf/core/series.py	91.25% <95.83%> (+0.47%)	⬆️
python/cudf/cudf/core/column/categorical.py	91.62% <100.00%> (+0.23%)	⬆️
python/cudf/cudf/core/column/datetime.py	89.09% <100.00%> (ø)
python/cudf/cudf/core/column/string.py	86.58% <100.00%> (+0.08%)	⬆️
... and 15 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0b766c5...6163360. Read the comment docs.

[ttnghia]

"string_pair" should mean a pair of strings, so should we use some other name?

[davidwendt]

Most usages of 'pair' indicate two different types.

[harrism]

Well, I don't agree with that statement... but I also don't have a better name suggestion.

[ttnghia]

The pair contains data pointer and data size, similar to a span. How about string_span?

[jlowe]

Thanks for working on this, @davidwendt! I have a small comment suggestion, but otherwise this looks good to me. I ran this on the dataset from #7545 and make_strings_column is now 28.5 msec instead of 371.2 msec. Not too shabby! The cost is still a lot larger than what is spent decompressing and decoding the strings from Parquet for this dataset, but it's a huge improvement from where it was.

[davidwendt]

... The cost is still a lot larger than what is spent decompressing and decoding the strings from Parquet for this dataset, but it's a huge improvement from where it was.

We discussed that maybe a better solution is for the Parquet reader to just build the chars and offsets directly instead of using this factory function. But this improvement will also be good for other places that use the factory.

[jrhemstad]

We discussed that maybe a better solution is for the Parquet reader to just build the chars and offsets directly instead of using this factory function. But this improvement will also be good for other places that use the factory.

I discussed this with @devavret and there really isn't anything better they can do in the Parquet reader other then reinventing the implementation of this factory. The string data in the Parquet layout is stored as {string, size, string, size, ...}. So there's no better way to do it than coalescing a bunch of disparate string_views.

[kkraus14]

@gpucibot merge