Thanks for opening a PR! Could you please create a JIRA for it?

cc @ffacs @luffy-zh

@wgtmac could you help review this pr, thanks very much

@taiyang-li Hi, thank you for opening a PR!
.Do writing cost a lot on sorting? After all, the size of dictionary shouldn't be large when we try to use dictionary encoding.

@taiyang-li Hi, thank you for opening a PR! It seems that the time complexity not changed. Do writing cost a lot on sorting? After all, the size of dictionary shouldn't be large when we try to use dictionary encoding.

@ffacs I had measured about this. From flamegraph we could see that std::map::insert takes most of time. Notice that std::map::insert is executed even if key is duplicated. Anyway, I'll add a microbench for comparison.

@taiyang-li Hi, thank you for opening a PR! It seems that the time complexity not changed. Do writing cost a lot on sorting? After all, the size of dictionary shouldn't be large when we try to use dictionary encoding.

@ffacs I had measured about this. From flamegraph we could see that std::map::insert takes most of time. Notice that std::map::insert is executed even if key is duplicated.

Oh yes, std::map takes $$O(n \ \log(key))$$, but sort takes only $$O(n + key\ \log(Key))$$

@ffacs do you know where can I add google benchmark in orc ?

@ffacs do you know where can I add google benchmark in orc ?

There are no C++ benchmark currently. FYI. #1658

I added a benchmark src/Common/benchmarks/orc_string_dictionary.cpp in another related ClickHouse PR (https://github.com/ClickHouse/ClickHouse/pull/68591/files) to measure performance changes after my optimization. Here is the result. @ffacs @luffy-zh hope for your reviews.

$ ./build_gcc/src/Common/benchmarks/orc_string_dictionary 
2024-08-26T15:00:09+08:00
Running ./build_gcc/src/Common/benchmarks/orc_string_dictionary
Run on (32 X 2100 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x16)
  L1 Instruction 32 KiB (x16)
  L2 Unified 1024 KiB (x16)
  L3 Unified 11264 KiB (x2)
Load Average: 6.35, 7.05, 6.55
------------------------------------------------------------------------------------------------------
Benchmark                                                            Time             CPU   Iterations
------------------------------------------------------------------------------------------------------
BM_writeStringDictionary<OldSortedStringDictionary, 10>       74094421 ns     74091713 ns            9
BM_writeStringDictionary<NewSortedStringDictionary, 10>       73200223 ns     73197770 ns            9
BM_writeStringDictionary<OldSortedStringDictionary, 100>     137097736 ns    137091909 ns            5
BM_writeStringDictionary<NewSortedStringDictionary, 100>      86304767 ns     86301101 ns            8
BM_writeStringDictionary<OldSortedStringDictionary, 1000>    237995798 ns    237986072 ns            3
BM_writeStringDictionary<NewSortedStringDictionary, 1000>    101562538 ns    101559063 ns            7
BM_writeStringDictionary<OldSortedStringDictionary, 10000>   397019465 ns    397002121 ns            2
BM_writeStringDictionary<NewSortedStringDictionary, 10000>   153278355 ns    153274828 ns            4
BM_writeStringDictionary<OldSortedStringDictionary, 100000>  787423737 ns    787397582 ns            1
BM_writeStringDictionary<NewSortedStringDictionary, 100000>  334958714 ns    334938666 ns            2 

OldSortedStringDictionary is the old implementation, NewSortedStringDictionary is the new implementation, and 10/100/1000/10000/100000 represents the cardinality number of strings among 10 million rows

Thanks for opening a PR! Could you please create a JIRA for it?

https://issues.apache.org/jira/browse/ORC-1767

@ffacs any new requested changes ?