Что такое хорошее средство выделения памяти C для встроенных систем? [закрытый]
Это невозможно в большинстве, если не во всех современных браузерах. Даже если вы отключите right click или ctrl + u или ctrl + shift + i, в Google Chrome все равно есть возможность просмотра источника страницы (только браузер, который я могу проверить).
Как уже упоминали другие люди, вы можете минимизировать свой код, чтобы омрачить его, но даже это можно «расшифровать», если у вас есть кто-то, у кого достаточно времени, чтобы посмотреть на этот отвратительный код.
6 ответов
Я провел некоторое исследование по этой самой теме недавно, поскольку у нас была проблема с фрагментацией памяти. В конце мы решили остаться с реализацией libc's GNU и добавить некоторые пулы памяти прикладного уровня в случае необходимости. Были другие средства выделения, которые имели лучшее поведение фрагментации, но мы не были достаточно довольны ими, заменяют malloc глобально. GNU обладает преимуществом долгой истории позади него.
В Вашем случае это кажется выровненным по ширине; принятие Вас не может зафиксировать VM, те крошечные выделения очень расточительны. Я не знаю, какова Ваша целая среда, но Вы могли бы рассмотреть обертывание вызовов к malloc/realloc/free на просто VM так, чтобы можно было выдать его к обработчику, разработанному для маленьких пулов.
В прошлом проекте в C я продолжил работать, мы пошли в будущем реализации наших собственных стандартных программ управления памятью для библиотеки, работал на широком спектре платформ включая встроенные системы. Библиотека также выделила и освободила большое количество маленьких буферов. Это работало относительно хорошо и не взяло большой объем кода для реализации. Я могу дать Вам немного фона на той реализации в случае, если Вы хотите разработать что-то сами.
базовое внедрение включало ряд стандартных программ, которые управляли буферами размера набора. Стандартные программы использовались в качестве оберток вокруг malloc () и свободные (). Мы использовали эти стандартные программы для управления выделением структур, которые мы часто использовали и также управлять универсальными буферами размеров набора. Структура использовалась для описания каждого типа управляемого буфера. Когда буфер определенного типа был выделен, мы были бы malloc () память в блоках (если бы список свободных буферов был пуст). IE, если мы управляли 10-байтовыми буферами, мы могли бы сделать единственный malloc (), который содержал пространство для 100 из этих буферов для сокращения фрагментации и количества лежания в основе mallocs необходимый.
Впереди каждого буфера был бы указатель, который будет использоваться для объединения в цепочку буферов в бесплатном списке. Когда 100 буферов были выделены, каждый буфер будет объединен в цепочку вместе в бесплатном списке. Когда буфер использовался, указатель будет установлен в NULL. Мы также вели список "блоков" буферов, так, чтобы мы могли сделать простую очистку путем называния свободным () на каждом из фактических буферов malloc'd.
Для управления динамическими буферными размерами, мы также добавили size_t переменную в начале каждого буфера, говоря размер буфера. Это тогда использовалось для идентификации, какой буферный блок отложить буфер в то, когда это было освобождено. У нас были заменяющие стандартные программы для malloc () и свободный (), который сделал адресную арифметику с указателями, чтобы получить размер буфера и затем поместить буфер в бесплатный список. У нас также был предел на то, как большой из буферов мы справились. Буферы, более крупные, чем этот предел, были просто malloc'd и передали пользователю. Для структур, что мы справились, мы создали стандартные программы обертки для выделения и освобождения от определенных структур.
В конечном счете мы также развили систему для включения сборки "мусора", когда требовал пользователь очистить неиспользованную память. Так как мы управляли целой системой, была различная оптимизация, которую мы смогли сделать со временем для увеличения производительности системы. Как я упомянул, это действительно работало вполне хорошо.
Хотя его прошедший некоторое время, так как я спросил это, мое конечное решение, должен был использовать SmallObjectAllocator LoKi, это работает отлично. Избавленный от всей ОС звонит и улучшенный производительность моего механизма Lua для встроенных устройств. Очень хороший и простой, и примерно ценность 5 минут работы!
С тех пор версия 5.1 , Lua позволила пользовательское средство выделения быть установленной когда создающие новые состояния .
Я использовал систему «двоичного друга» для хорошего результата в vxworks. По сути, вы разделяете свою кучу, разрезая блоки пополам, чтобы получить наименьшую мощность блока двух размеров для хранения вашего запроса, а когда блоки освобождены, вы можете пройти вверх по дереву, чтобы объединить блоки обратно вместе, чтобы уменьшить фрагментацию. Поиск в Google должен предоставить всю необходимую информацию.
Я также хотел бы добавить к этому, хотя это старый поток. Во встроенном приложении, если вы можете проанализировать использование памяти для своего приложения и придумать максимальное количество выделений памяти различных размеров, обычно самый быстрый тип распределителя - это тот, который использует пулы памяти. В наших встроенных приложениях мы можем определить все размеры выделения, которые когда-либо понадобятся во время выполнения. Если вы можете это сделать, вы можете полностью исключить фрагментацию кучи и получить очень быстрое распределение. В большинстве этих реализаций есть пул переполнения, который будет выполнять регулярный malloc для особых случаев, которых, надеюсь, будет немного, если вы правильно сделали свой анализ.