Miсrosoft открыл код системы распределения памяти mimalloc
https://github.com/microsoft/mimalloc

Подключается очень просто
env MIMALLOC_VERBOSE=1 LD_PRELOAD=/usr/local/lib/libmimalloc.so /opt/1C/v8.3/x86_64/1cestart
MIMALLOC_VERBOSE чтобы посмотреть что оно вообще подключилось

Файловый Гивева без mimalloc 108.7, с mimalloc 119.05
Проверял несколько запуская несколько рез и так и сяк. Цифры повторяются.

Почти на 10% быстрее.

Кто решиться проверить в серверном варианте?

Не-не-не. Мы подождем, пока вендор скажет своё веское слово.

(1) А зачем и почему это должно им потребоваться?
Первое же правило - работает - не трожь ;)
Лет через 10 может что-то и скажут, когда дойдут до встроенного аллокатора памяти.

Но уж раз такая фича у Linux есть: просто так вот взять и подметить одну совместную библиотеку на другую, совместную с ней, почему бы и нет? Если в МС не накосячили - проблеем быть не должно.
Это нормальное явление, например подменить libjpeg, но libjpeg-turbo никаких проблем не вызывает, только ускоряет...
Что, в 1С вот так сильно поверяют библиотечные вызовы malloc? В каждом дистрибутиве?
Ой, да ладно, на уровне - не упало уже хорошо ;)

Поставлю на файловую. А чё? Копии то есть ;)

Надо еще обновление на тесте накатить/проверить, правда замерить сложнее.

(0) Плохо у тебя с математикой....
Между 108 и 109 не 10%, а меньше 1%

(3) ай шайтан, невниматеьный)

еще всякие сеансе данные в tmpfs положи

сеансовые

(2) Я, вообще-то, Торвальдса имел ввиду. Вот когда он скажет, что можно в ядро эту поделку от МС запихнуть, тогда будем пихать. С malloc'ами не шутят.

(7) Этот аллокатор не в ядре, это замена glibc. Так что от Торвальдса ты тоже ничего не дождешься ;)
Таких аллокаторов довольно много разных, по ссылке в (0) есть их сравнение.

(5) 7чные там и держу, 8чные слишком толсто ;( Правда винт nvme так что не так критично.

(0) спс за инфу, судя по тестам намного быстрее стандартной glibc.
:fkm ntcnbnm yt yf rjv ))

Попробовал tcmalloc на файловой базе, прирост в районе 10%.
jemalloc какого-то заметного влияния не оказал. Postgres-у оба пофиг.
Можно будет посмотреть еще сервер приложений, будет прирост какой или нет...
Конечно, не для рабочих баз.

(10) У PostgreSQL свой менеджер памяти.

А вот почему это не для рабочих баз? Только что наткнулся...
Использование менеджера динамической памяти TCmalloc с платформой 1С:Предприятие версий 8.3.10-8.3.14
https://kb.1c.ru/articleView.jsp?id=128

(11) За ссылку спасибо.
Те есть, вендор (1С, не Тровальдс), в принципе(неявно), не против. А "официальных" рекомендаций от 1С не находилось? Хотя, это надо тестировать на разных дистрибутивах и конфигурациях, собирать статистику...

(5) Сервер приложений, запущенный с TCmalloc, на твоем тесте дает 10%-й выигрыш, по всем тестам. Компенсируя, тем самым, падение на те же примерно 10%, которые вносит 8.3.14, по сравнению с предыдущими версиями платформы.
Надо будет посмотреть на 8.3.15.
На тесте Гилева выигрыш меньше, почему-то.

(11) Тем не менее, им(аллокатором) тоже не все довольны https://www.postgresql.org/message-id/CA%2BTgmobkeWptGwiNa%2BSGFWsTLzTzD-CeLz0KcE-y6LFgoUus4A%40mail.gmail.com

Недельки 2 прошло кажется?
Небольшой отчет значит:
Поставил на файловую в терминалке на Linux.
Рекламаций от бухов нет, потребление памяти уменьшилось на 600 метров при обычной закачке из КД 2.0.
Ускорение уже вычисляли, НО!
Хотелось бы в 10 раз ускорение, но так просто это не бывает ;)