Исходное сообщение
"Выпуск языка программирования Ruby 2.7.0" Отправлено Аноним84701, 26-Дек-19 01:09
>>  выполнять дефрагментацию области памяти, решая проблемы снижения производительности > Кто в теме, объясните нубу, как дефрагментация памяти повысит производительность? Это же > не диск, где головка туда-сюда дёргается, там просто адрес ячейки. Это, скорее всего, вот отсюда: https://www.ruby-forum.com/t/heap-fragmentation-in-a-long-ru... > Thanks to Jamis B. [5] and Mauricio F. [6] I was able to determine that the application was stuck for several seconds in glibc’s realloc, which may be called (via ruby_xrealloc) from basically anywhere within ruby where a new or enlarged chunk of memory might be required. [...] > And then - all praise bugzilla - I found a bugreport [8] describing almost exactly my problems and leading me to ptmalloc3 [9]. [...] > As far as I understand, ptmalloc3 does not eliminate heap fragmentation. > However, due to the bit-wise tree employed in the newer version, it finds free chunks of the right size in shorter time by several orders of magnitude. Additionally, it seems that glibc 2.5 abandons its attempts to find a best-fit chunk after a while (possibly after 10000 tries), т.е. проблема поиска свободных блоков памяти при сильной фрагментации - "приветик" от создания короткоживущих объектов "на каждый чих".

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> выполнять дефрагментацию области памяти, решая проблемы снижения производительности >> Кто в теме, объясните нубу, как дефрагментация памяти повысит производительность? Это же >> не диск, где головка туда-сюда дёргается, там просто адрес ячейки. > Это, скорее всего, вот отсюда: > https://www.ruby-forum.com/t/heap-fragmentation-in-a-long-running-ruby-process/109742 >> Thanks to Jamis B. [5] and Mauricio F. [6] I was able to determine that the application was [b]stuck for several seconds in glibc’s realloc, which may be called (via ruby_xrealloc) from basically anywhere within ruby where a new or enlarged chunk of memory might be required.[/b] > [...] >> And then - all praise bugzilla - I found a bugreport [8] describing almost exactly my problems and leading me to ptmalloc3 [9]. > [...] >> As far as I understand, ptmalloc3 does not eliminate heap fragmentation. >> However, due to the bit-wise tree employed in the newer version, it [b]finds free chunks of the right size in shorter time by several orders of magnitude.[/b] Additionally, it seems that glibc 2.5 abandons its attempts to find a best-fit chunk after a while (possibly after 10000 tries), > т.е. проблема поиска свободных блоков памяти при сильной фрагментации - "приветик" от > создания короткоживущих объектов "на каждый чих".
	Введите код, изображенный на картинке: