TSan report in base64_codec_choose.

[alexey-milovidov]

https://clickhouse-test-reports.s3.yandex.net/0/8d1165ed9217f6e512dff65167ae495094daf90e/stress_test_(thread)/stderr.log

Not a bug. Trivial.

[alexey-milovidov]

https://github.com/aklomp/base64 has poor design of initialization
and at least two new competitive libraries exist:
https://github.com/lemire/fastbase64
https://github.com/powturbo/TurboBase64

[alexey-milovidov]

We usually encode and decode huge amount of short strings (instead of one large string), so the relevance of benchmarks of these libraries are in question.

[alexey-milovidov]

TurboBase64 library looks half baked and it doesn't support strings longer than 4 GiB.

Update: now it does!

[alexey-milovidov]

The library TurboBase64 is at least tens percent worse than aklomp/base64 on test:

clickhouse-benchmark <<< "SELECT sum(length(base64Encode(URL))) FROM test.hits"

localhost:9000, queries 2319, QPS: 8.579, RPS: 76129062.788, MiB/s: 6283.060, result RPS: 8.579, result MiB/s: 0.000.

0.000%          0.094 sec.
10.000%         0.102 sec.
20.000%         0.105 sec.
30.000%         0.108 sec.
40.000%         0.110 sec.
50.000%         0.113 sec.

localhost:9000, queries 1483, QPS: 7.669, RPS: 68056225.151, MiB/s: 5616.795, result RPS: 7.669, result MiB/s: 0.000.

0.000%          0.097 sec.
10.000%         0.108 sec.
20.000%         0.115 sec.
30.000%         0.121 sec.
40.000%         0.125 sec.
50.000%         0.130 sec.

This is due to processing of "tails".

[alexey-milovidov]

The branch with TurboBase64 can be found here: https://github.com/ClickHouse/ClickHouse/compare/base64-update