Оптимизация: типичные ошибки программистов и как их можно исправить

[dersoverflow]

Видно, что tcmalloc быстрее стандартного аллокатора в пять раз

попробуйте ders::mem_pool.

по результатам тестирования list<int, mp_allocator<int>> получается ускорение в 5-8 раз. здесь результаты: https://ders.by/cpp/norefs/norefs.html#4.2

а sh_ptr с mp_allocator в 6-12 раз!

но самое смешное - это ввод/вывод! ders::buf_rd дает ускорение в 10-33 раза.

[vsnikolaev]

Какое же язвительно изложение по ссылке...

[ppreblagin]

Не слышали, но будем иметь в виду, спасибо.

[dersoverflow]

мы разобрались с традиционным противостоянием std::map против std::unordered_map, есть смысл посмотреть на альтернативные реализации

еще посмотрите ders::blob_map - в 14 раз быстрее unordered_map<string, string> на 64 потоках.

здесь: https://ders.by/cpp/memdb/memdb.html#5.1

[dersoverflow]

(dup)

[Tuxman]

Логирование

Рейт лимит не завезли?

Выбор аллокатора

Tcmalloc? У вас там треды? Тогда надо про треды пейсать. А иначе, если топик про c++, то давайте вспомним c++17 std::pmr::polymorphic_allocator

... низкий уровень материала.

[ppreblagin]

Рейт лимит не завезли?

Так дело не только и не столько в этом. Рейт лимит не избавляет от вызовов логгера, а приводить к потере производительности они могут и без реальной записи сообщения куда-либо.

Tcmalloc? У вас там треды? Тогда надо про треды пейсать. А иначе, если топик про c++, то давайте вспомним c++17 std::pmr::polymorphic_allocator

Так вспомнили же.

[Panzerschrek]

Про оптимизацию выкидывания strlen - недавно где-то читал (может на Хабре), что strcpy быстрее работает, если сначала пройтись по исходной строке и посчитать длину, а потом уже скопировать, заиспользовав мощь векторных инструкций. Если же сразу и проходить по строке и проверять длину, то так не выйдет сделать и компилятор не сможет код векторизовать.

[redfox0]

Там провал в производительности не из-за компилятора, а что первый проход по строке загружает данные из памяти в кеши процессора, и второй проход оказывается быстрее. Хотя с алгоритмической стороны стоимость будет одинаковой при каждом чтении.

[ppreblagin]

Мне кажется, @redfox0 прав. Плюс сходил в исходники glibc (https://elixir.bootlin.com/glibc/glibc-2.40.9000/source/sysdeps/x86_64/multiarch), и там уже есть векторизированные вручную варианты этих функций.

[Timur_Sennikov]

  const size_t len = strlen(s);
  for(size_t i = 0; i < len; ++i) {
      asm volatile("" : "+m,r"(dumb) : : "memory");
  }

Можно написать как

for(size_t i = 0, len = strlen(s); i < len; ++i) {
    asm volatile("" : "+m,r"(dumb) : : "memory");
}

По идее и убывания производительности не будет, потому что длина строки вычисляется только раз, и ничего лишнего вне цикла писать не надо, если я не прав - поправьте пожалуйста

[ppreblagin]

Да, так и есть, это эквивалентные конструкции.

[sergio_nsk]

Например, прогнав микробенчмарк для одного из типовых сценариев, получили следующую картину.

Можно увидеть код этого бенчмарка? Что-то уж слишком большое замедление у других известных аллокаторов.