| 1.1, нах. (?), 22:16, 18/09/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Фейсбук за все берется смело... боюсь получится как с memcache.
| | |
| 1.3, Ivan_83 (ok), 22:33, 18/09/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Ни одной буквы о том как изменилась производительность.
Подозреваю что там никаких улучшений нет уже лет 10, а автор перевёл его в архив потому что делать там больше нечего, всё и так прекрано работает.
| | |
| |
| 2.5, Аноним (4), 22:41, 18/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
Потому что mimalloc быстрее и эффективнее, конкурировать с ним пустое дело. Сабж позволяет решать специфические задачи специфического оборудования. В кластерах, да. Если рассматривать сабж на примере жырнолиса, можно ему зажать пиковую память, но тогда тормозит очень сильно. Почему каждые 3 секунды выделяет и удаляет по гигабайту памяти на твиче, никто так и не объяснил. Иногда просто начинает течь. Если поменять на mimalloc (требует перекомпиляция), не течёт.
| | |
| |
| 3.9, Аноним (9), 23:47, 18/09/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Потому что mimalloc быстрее и эффективнее
Только память освобождать не умеет, лол.
| | |
| 3.12, вымя (?), 00:20, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
> mimalloc
> конкурировать с ним пустое дело
...по части багов. В одном только solvespace с ним постоянная возня и необходимость прибивать конкретные версии:
> Confirmed that going back to the vendored mimalloc fixes it
> This is fixed in v2.2.4, but we unfortunately can't use it due to another issue (microsoft/mimalloc#1124), so we have to downgrade for now until it is fixed.
> mimalloc has been the least reliable dependency | | |
| 3.13, Ivan_83 (ok), 00:24, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
Без понятия как там быстрее или нет mimalloc, я не замечал чтобы у меня что либо тормозило.
Нормально написанный софт аллокатор лишний раз не дёргает.
В случае браузера - возможно, там же джава внутри может какой угодно какакод запускать.
Лису я тоже память на уровне системы ограничил, но так чтобы он меня часто не беспокоил своим перееданием и тормозами.
Твич не юзал, вероятно какахокодеры на жабаскрипте там что то учудили.
| | |
| 3.14, Ivan_83 (ok), 00:29, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Я как бы целом имел ввиду что аллокатору развиватся особо некуда.
Один раз выбрали стратегию, выбрали свой баланс и всё.
За все годы разве что huge pages отрасли и ещё очень по мелочи всякие флаги для mmap(), и sbrk() выкинули. На этом всё развитие и кончается. Раз в 5 лет только поглядывать что по мелочи подкорректировать под текущие стандарты языка С, и специфики системы.
Если кто то там до сих пор каждую неделю или месяц релизит свой аллокатор - я бы от такого держался по дальше - люди явно эксперементируют и там процесс ради процесса а не для результата.
| | |
|
| 2.15, вымя (?), 00:31, 19/09/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Ни одной буквы о том как изменилась производительность.
> This release contains over 160 commits, focusing on the technical debts cleaning including refactorings, bug fixes, test coverage improvement, and option cleanups.
Все ускорения они ещё в 5.3 обещали. Но смысла никакого верить красивым чиселкам нет, надо тестировать каждое приложение отдельно, потому что паттерн выделения памяти у всех разный. Бывает даже так:
> Using jemalloc as Ruby’s default is a bit problematic. There was a heated discussion in the Ruby bug tracker about this, but in the end no decision was made. The main issue raised is the fact that memory usage only reduces when using jemalloc 3; memory usage is still high when using jemalloc 5. Nobody knows why, so that makes the choice of defaulting to jemalloc very dodgy. | | |
|
| 1.8, Аноним (8), 23:33, 18/09/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ненужно. Если требуется специальное управление памятью, то сам напишу. Функциями ос никто ещё пользоваться не запрещал, не все правда про них знают почему-то.
| | |
|
