У вас правда приложение проводит десятки процентов процессорного времени в

malloc?

что значит десятки. у меня вот сервер опроса по модбасу на Qt проводит в malloc 86% ибо на каждый запрос создается свой reply (привет Qt) вы скажите ну возьмите напишите свой сервер + напишите пулл обьектов для reply... вообще кто придумал эти фреймворки... надо же все самим писать.

ух жесть то какая

А платформа какая и железо? Мне просто интересно

ну самое забавное, что выделяем то детские 256 байт для модбас пакета. + qObject делает второе выделение для своего pimpl. просто работа сервера опрос девайсов, и генерация событий для АРМ оператора. получается опросили, сложили регистры в общую карту, проверили по маске если что-то стоит, сообщяем оператору. повторяем цикл. получаем что больше всего торчим в выделении памяти для reply

серверная убунту. ну железо разное, в основном промышленный ПК боксер. если АРМ совмещен с сервером, то всякие iRobo или китайский аналог. но туда уже стявят линух с GUI скажем кубунту в последний раз ставили.

для начала - зачем создавать QObject на каждый запрос?

ну что значит зачем. reply явл-ся КОбжект! потом не я же его создаю. мне его клиент возвращает при запросе. Почему нельзя переиспользовать reply? ну это вы у авторов Qt спросите. новый запрос - новый reply.

Можно попробовать подключить кастомный алокатор и переопределить new только для объекта reply. Как тут https://www.qt.io/blog/a-fast-and-thread-safe-pool-allocator-for-qt-part-1

Ну Qt это считай Java, там производительностью никогда не пахло

У вас просто такой сценарий использования что возможно лучше не использовать qt для модбаса. Оно же слабо предназначено для опроса большого количества устройств

Это.... Говори за себя пожалуйста. Все там ок с производительностью

"Qt считай Java" ну тут разговор можно даже не начинать

Qt сильно не кэш френдли если абсолютно всё в системе не на Qt и не одной версии (очень скучаю по смартфонам Nokia Series S60, где как раз так было), это да, тоже не люблю Qt из-за этого, но это далеко не Java или C# где неотключаемый сборщик мусора и огромный рантайм с бесконечными пересборками всего на лету, которые убивают мобильность (батарею) и порой создают лаги в неподходящий момент

я к этому

А что, все так вот должны прям совсем быть cache friendly ?

при прочих равных - да, было бы очень неплохо

Кэш имеет только одну стратегию, вовсе не факт, что она будет ложиться под все виды приложений.

Спасибо, классная опечатка))) cache, не cash...

можно привести около-реальные примеры, где cache-friendly библиотека будет только вредить для перфа?

Ну и далее постановка вопроса неверная. Не приложение для кэша, а кэш для приложения.

так никто и не собирается переписывать приложение. тут всего лишь запрос к библиотеке быть cache friendly, если она таковой может быть

Исправил, сорри

В рамках облака это была бы не опечатка..

+ очень много

А тот факт, что это реально кучи динамических аллокаций всего и вся? Если это не какой-нибудь UI, где можно однажды аллоцироваться и успокоиться, то использование подобного фреймворка - настоящая катастрофа для мемори-менеджмента, даже в отрыве от нелокальности, не? Фрагментация, лукапы, куча системного сервисного мусора для каждой аллокации.

Поэтому есть FastPimpl

Подумать только, мы динамически аллоцируем все подряд, референсим в родителей, динамически (ре)аллоцируя память в референс-контейнерах родителей таким образом. Можно даже картинку соответствующую вставить на тему "чтобы аллоцировать пока аллоцируешь".

В Qt не используется, насколько я знаю.

Но в Qt это не завезли, там pimpl выделяется в хипе

Хип тоже уже довольно давно не так страшно, как было раньше

Ну как сказать. Если верить вики dlmalloc появился где-то в 1987 году. С тех пор на сколько я знаю в ptmalloc добавили трэдлокал кеширование и ... это все изменения которые произошли. Ну еще некоторые эксплойты перекрыли. Кажется единственное что изменилось - это железо стало быстрее, благодаря чему gui можно писать как угодно. Если же забыть про не требовательные к перфу задачи вроде gui, паттерн доступа к памяти все еще играет важную роль.

Речь о том, что за редким исключением на с++ даже если писать в стилистике шаред птры + всякие анордеред мапы, все равно будет быстро )

Даже на электроне