Что тут непонятного, посчитайте сколько тот массив table займет с макросами объявленными по дефолту, прикиньте размер объявленных типов, сделайте поправку на выравнивание, прикиньте средний размер выделяемого блока, рассчитайте их количество, умножьте на размер служебной структуры, опять учтите выравнивание, добавьте процент который авторы оставляют на фрагментацию и прикиньте сколько разработчик оставит резерва чтобы не упереться в потолок. 20K еще будет оптимистично.
И это в то время когда есть приемлемые методы вообще без фрагментации и более быстрые.
А я чтоль противник TLSF?
Тока уточняю особенности ее тактического применения
Цитата(sergeeff @ Jul 10 2009, 14:18)
Никак не могу понять, откуда вы взяли цифру 20К, которую съедает TLSF? Да, там есть накладные расходы на каждый выделяемый блок. Но именно эта дополнительная информация и позволяет минимизировать ту самую фрагментацию, о которой вы говорите. Из статически выделяемых - один массив table[]
Я не агент по продвижению TLSF и привел этот проект как современный и любопытный в своей реализации. Так что "страшилки" про пожираемую им память как-то не очень обоснованы.
Посоветуйте готовый менеджер памяти
Jul 9 2009, 13:01
