sonntex 25 ноя 2019 в 18:00

Проблема частого создания и удаления объектов в C++

11 мин

9.7K

Open source*Программирование*C++*C*

+15

Комментарии 11

Fyret 25 ноя 2019 в 18:39

Рассматривался ли вариант использования tmalloc, jmalloc и т.п.? И если да, то почему был отброшен?

sonntex 25 ноя 2019 в 19:11

Да, рассматривался вариант с tcmalloc. Если посмотреть на скриншоты amplifier, то видно, что tcmalloc как раз и используется (woslab, clodslab и hotslab). С ним ушла фрагментация в большей степени. Но перестроение его внутренних кэшей на таких потоках данных, как у нас, все равно заметно и сильно влияет на время вызова operator new и operator delete.

sonntex 25 ноя 2019 в 19:11

<удалено>

thatsme 25 ноя 2019 в 21:38

mimalloc значительно быстрее tcmalloc, пробовали?

sonntex 25 ноя 2019 в 22:05

К сожалению, нет. Почитал описание на github — стоит поэксперементировать. Тем более, что недорого в плане времени. Спасибо!

wxmaper 26 ноя 2019 в 03:44

пишет свою собственную систему фильтрации трафика и защищает с помощью нее бизнес от DDoS-атак, ботов, парсеров, а также многого другого.

Не понимаю, почему все пытаются защититься от парсинга? Пустая трата ресурсов и времени, информацию всё равно достанут. И чем сложнее её будет достать, тем агрессивнее будут методы её получения.
Лучше бы наоборот старались предоставить самый простейший инструмент для выкачивания информации.
Взять тот же 2gis — как то была статья на хабре, что из 2гис слишком легко доставать инфу и они не пользуются никакими защитами, мол какие нехорошие ребята. А что нехорошего? Это же наоборот прекрасно — если информацию в любом случае можно получить, зачем стараться усложнить способы её получения? Зачем платить за защиты, которые не будут работать (я говорю именно о парсинге). Зачем нагружать специалистов изобретать способы предотвращения парсинга, если это только усложнит обслуживание ресурса.

barabanof 26 ноя 2019 в 13:40

Есть множество различных причин, по которым может возникать потребность в ограничении к автоматическому доступу к информации:

парсеры нагружают ресурс, и эта нагрузка может составлять до 50% от трафика
информацию можно использовать для получения конкурентных преимуществ, например для поднятия своего предложения в товарном аггрегаторе при сортировке по цене

И так далее. Аргумент про то, что все равно достанут, вечен. Как и противостояние снаряда и брони. Остановить нельзя, можно только продолжать совершенствовать технологии.

svr_91 26 ноя 2019 в 10:28

А не получилось так, что за счет оптимизации одной части кода (выделение/освобождение памяти) замедлилась другая часть кода (бизнес-логика)? Как-то можно замерить, сколько времени ушло целиком на отработку всех запросов?

sonntex 26 ноя 2019 в 10:42

Да, конечно, замеры производились с помощью wrk и yandex-tank. Наши сервисы работают в разных режимах и где-то, где бизнес-логика простая, прирост производительности показал те же 50%+, а где сложнее — порядка 30-40%. Но тут зависит от архитектуры вашего приложения. Если вы обрабатываете цепочку <чтение запроса> -> <обработка запроса> -> <запись запроса> -> <чтение ответа> -> <обработка ответа> -> <запись ответа> в одном и том же потоке, то влияние на бизнес-логику может быть минимальным.

svr_91 26 ноя 2019 в 11:35

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

sonntex 26 ноя 2019 в 14:31

Если об этом, то получилось примерно так:

std::deque либо ограничиваем в размере, либо переводим на std::list (редко), либо оставляем на стандартном аллокаторе (редко, блокеры)
std::vector — смотри 1
std::string либо не используется (работаем с бинарными данными из variti::chunk и variti::streambuf через стандартные алгоритмы), либо оставляем на стандартном аллокаторе (редко, блокеры)
std::unordered_map не используется (размеры наших коллекций небольшие и данные редко меняются после инициализации, а еще надо помнить о том, что вычисление хэш-функции может быть дорогим занятием, поэтому мы храним данные в std::deque, сортируем его через std::sort, а потом ищем в нем с помощью std::lower_boud)

Итого, у нас было не так много подводных камней, как кажется. В производительности мы потеряли больше на репостах в соответствующие io контексты делитеров slab объектов, чем на алгоритмах хранения и обработки данных.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

Проблема частого создания и удаления объектов в C++

Комментарии 11

Публикации

Истории