Я реализовал алгоритм 1) с использованием обычного копирования строки и 2) с boost :: string_view для поиска суффиксной части строки после разделителя. Я профилировал код и, как мне показалось, стал интуитивно понятным, что boost :: string_view работал плохо.
std::string algorithm1(const std::string &mine, const std::string& path) {
size_t startPos = mine.find(path);
std::string temp;
if (startPos != mine.npos) {
startPos += path.size();
temp = mine.substr(startPos);
} else {
std::cout << "not found" << std::endl;
return "";
}
return temp;
}
boost::string_ref algorithm2(boost::string_ref mine, boost::string_ref path) {
size_t startPos = mine.find(path);
boost::string_ref temp;
if (startPos != mine.npos) {
startPos += path.size();
temp = mine.substr(startPos);
} else {
std::cout << "not found" << std::endl;
}
return temp;
}
int main(int argc, char* argv[])
{
std::cout << "entered" << std::endl;
const std::string mine = "sth/aStr/theSuffixWeDesire";
const std::string path = "/aStr/";
for (size_t i = 0; i < 10; i++)
{
assert (algorithm1(mine, path) == "theSuffixWeDesire");
assert (algorithm2(mine, path) == "theSuffixWeDesire");
}
return 0;
}
Когда я профилировал код с помощью uftrace, я получал для каждой итерации: «Алгоритм1», занимающий 2 083 нс, внутренне вызывает алгоритм std :: find2, берущий 11 835 нс с максимальным временем, затрачиваемым на вызов «std :: search». Возможно, я мог бы подумать о трех причинах:
- попадание в кэш процессора Алгоритм1, тогда как алгоритм2 вызывает библиотеку буста и, следовательно, отсутствует кэш ЦП и приводит к снижению скорости
- Операции Std оптимизируются компилятором, тогда как операции буста нет.
- std :: search, который использует буст, не хорошая замена std :: find.
Какие из этих объяснений более правдоподобны? Это было неожиданное поведение, заставило меня усомниться в использовании boost :: string_ref в моей кодовой базе. В моей системе g cc 5.4.0 (C ++ 14), повышение 1.66, нет флагов оптимизации компилятора (начиная с -O).
Спасибо,