|
|
  |
Экономия RAM. |
|
|
|
Mar 13 2016, 11:54
|

Гуру
     
Группа: Свой
Сообщений: 2 076
Регистрация: 10-09-08
Пользователь №: 40 106

|
Цитата(adnega @ Mar 13 2016, 14:31)  Почитайте сообщение №51. Не имею возражений к Вашему сообщению №51 И мне кажется что ТС сам же и ответил на свой вопрос написав: Цитата(Jenya7 @ Mar 8 2016, 10:38)  ...закончился RAM. а я еще даже не начал писать. Т.е. на этапе проектирования количество необходимой памяти не определено даже приблизительно. О каких менеджерах вообще может идти речь?
|
|
|
|
|
Mar 13 2016, 12:17
|
Гуру
     
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702

|
Цитата(zombi @ Mar 13 2016, 14:54)  Т.е. на этапе проектирования количество необходимой памяти не определено даже приблизительно. О каких менеджерах вообще может идти речь?  Мы с zltigo привели реальные примеры, когда пересмотр архитектуры позволил "найти" нужное количество памяти. Если ТС не способен ухитриться (или задача не позволяет), то для него путь - тупо увеличить объем ОЗУ. Отрицать на вашем месте вообще подход с использованием менеджеров памяти - не профессионально.
|
|
|
|
|
Mar 13 2016, 12:20
|
Профессионал
    
Группа: Участник
Сообщений: 1 778
Регистрация: 29-03-12
Пользователь №: 71 075

|
Цитата(ViKo @ Mar 13 2016, 17:06)  В однозадачном режиме использовать кучу безопасно. Выделил фрагмент, попользовался, освободил. Сложнее, когда задач несколько, и каждая может попросить памяти. Как определить худший случай, когда требуется максимальный объем? тут нужно решать концептуально. есть 10 задач. либо загрузить их в RAM и проходить итерацией , либо брать по одной - загрузил-освободил - тогда можно и с malloc/free. но во втором случае возникает вопрос - где держать задачи. хорошо. я написал код для PLC. В Ladder Diagram или мнемоник. где хранится пограмма которую PLC исполняет? идея.положу во флеш..если останется место. он что то тоже стремительно убывает.
Сообщение отредактировал Jenya7 - Mar 13 2016, 13:35
|
|
|
|
|
Mar 13 2016, 14:14
|
Гуру
     
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702

|
Цитата(zombi @ Mar 13 2016, 15:25)  Обвинять кого либо в том чего он не говорил - не порядочно. Значит менеджеры памяти в некоторых задачах нужны. Пригодность задачи для использования динамического выделения памяти определяет разработчик. Если задача непригодна (пусть даже по причине отсутствия опыта у исполнителя) - наращиваем ОЗУ. Все - конфликт исчерпан. Я прошу меня простить, если с кем-то поступил не порядочно.
|
|
|
|
|
Mar 13 2016, 21:19
|

Гуру
     
Группа: Свой
Сообщений: 2 076
Регистрация: 10-09-08
Пользователь №: 40 106

|
Цитата(adnega @ Mar 14 2016, 00:40)  Тема исчерпана - неплохо бы закрыть и последнее почистить. Ну значит так и есть  Удалил, мне не сложно. А насчёт "закрыть" это лучше к ТС писать Цитата(adnega @ Mar 13 2016, 17:14)  Значит менеджеры памяти в некоторых задачах нужны. Может СИшникам и нужны, мне точно не нужны. Для меня это просто часть алгоритма и как его обозвать не имеет значения.
|
|
|
|
|
Mar 14 2016, 08:24
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(ViKo @ Mar 14 2016, 10:48)  Создать глобальное объединение (union) из массивов всех нужных типов, максимально необходимого размера, и пользоваться им по мере необходимости вместо кучи. Годится? Хочу понять, как куча может помочь сэкономить память? Никак. Может привести только к бОльшему расходу памяти. Куча полезна только если нужно запускать различные задачи, заранее не известные (когда и какую), с заранее неизвестными требованиями к памяти. Но и то - нужна обработка случая нехватки памяти. Да и дефрагментация периодическая или после завершения каждой задачи. Это случай Linux-а и подобных ему систем. Обычно для ембеддед достаточно: union MemShare { struct MemMode1 { int member1, member2; ... } memMode1; struct MemMode2 { int member1, member2; ... } memMode2; ... } memShare; где Mode1, Mode2, ... - состояния работы устройства с неперекрывающимися структурами данных; которые в свою очередь могут быть union и делиться дальше.
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|