This regression was introduced in 8abab5c73dd6fc951cc22f21d89381e5b4e70c7d.
std::equal() is supposed to be faster than std::string::compare() and a benchmark even supports this: https://quick-bench.com/q/JkxxUMqC8wLufOw7AUI-l1K-n7Q. But somehow in our code it leads to a big performance regression when using the Clang compiler.
before
Benchmark 1: ./simplecpp -q -D__GNUC__ -D__x86_64__ -DHAVE_CONFIG_H -I ../../xrdp/build ../../xrdp/common/file.c
Time (mean ± σ): 166.8 ms ± 29.3 ms [User: 142.4 ms, System: 22.6 ms]
Range (min … max): 131.9 ms … 218.9 ms 12 runs
after
Benchmark 1: ./simplecpp -q -D__GNUC__ -D__x86_64__ -DHAVE_CONFIG_H -I ../../xrdp/build ../../xrdp/common/file.c
Time (mean ± σ): 11.5 ms ± 0.6 ms [User: 9.0 ms, System: 2.6 ms]
Range (min … max): 10.9 ms … 14.6 ms 216 runs
With GCC this also exists but is much less severe.
This regression was introduced in 8abab5c73dd6fc951cc22f21d89381e5b4e70c7d.
std::equal()
is supposed to be faster thanstd::string::compare()
and a benchmark even supports this: https://quick-bench.com/q/JkxxUMqC8wLufOw7AUI-l1K-n7Q. But somehow in our code it leads to a big performance regression when using the Clang compiler.before
after
With GCC this also exists but is much less severe.