У вас здесь всего лишь закончилась память, об этом ниже. В своём первом посте об этой библиотеке (пятый пост в этой теме) вы говорили о замедлении, сбое, и зависании. Меня интересуют именно вот эти явления. Аллокатор постоянной вычислительной сложности в принципе не может приводить к замедлению и зависанию сам по себе; если вы посмотрите исходники, вы не увидите там ни одного цикла (кроме как при вычислении двоичного логарифма, если быть максимально педантичным). Можете ли вы подтвердить, что вы действительно наблюдали описанные эффекты? Я склоняюсь к версии, что тест был выполнен не вполне добросовестно, и ваш первый отзыв вводит людей в заблуждение. Пожалуйста, либо внесите ясность, либо отредактируйте пост.
В плане эффективности использования памяти мой аллокатор лучше, чем альтернатива от zltigo и, скорее всего, лучше чем ваш аллокатор из стандартной библиотеки (не могу быть в последнем уверен, потому что не знаю, что у вас за стандартная библиотека). В системах не-реального времени традиционно делается упор на оптимизацию среднего или амортизированного худшего случая, при этом худший случай (особенно если он достаточно редок) интерес для анализа представляет сравнительно небольшой. В системах реального времени приоритеты обратные, но вам, как разработчику встраиваемых систем, это известно и так. Что вам может быть неизвестно, так это применимость принципа оптимизации среднего случая в контексте не только времени, но и фрагментации кучи. В обычных аллокаторах часто применяется стратегия поиска наилучшего соответствия (best-fit), о которой писал и zltigo:
Человеку не в теме это может показаться парадоксальным, но худший случай фрагментации кучи при использовании стратегии best-fit хуже, чем при использовании более простой стратегии поиска первого соответствия (first-fit). Я не буду утомлять вас матаном, но если вам это действительно интересно, обратите внимание на публикацию "Worst case fragmentation of first fit and best fit storage allocation strategies" [Robson 1977]. В моём аллокаторе используется first-fit, который, как вы уже поняли, показывает более высокую фрагментацию у вас на столе, но он при этом не сломается в полевых условиях у невезучего клиента, которому повезёт выбить из best-fit аллокатора редкую последовательность выделений памяти, что приводит к катастрофической фрагментации и отказу.
Большинство людей на этом форуме, в частности вы и уважаемый zltigo, ничего не понимают в аллокаторах, но я вас в этом не виню. Это довольно экзотическая область и нет ничего страшного в отсутствии столь узкоспециализированных познаний, нужно просто это аккуратно осознать. Меня задевает, что вы лезете в тему, в которой явно ничего не смыслите, и несправедливо критикуете работу других, не разобравшись в происходящем. Вам уже давали ссылку на мою статью на хабре, пожалуйста, прочитайте её и указанные в ней источники, если вы хотите разобраться в вопросе самостоятельно.
