2009-03-01 3 views
2

Программное обеспечение будет использовать память, не большой сюрприз, но как вы сохраняете это использование до минимума по сравнению с тем, насколько велика ваша программа.Способы сделать вашу программу меньше памяти

Лучший пример, я думаю, будет Firefox. Некоторые пользователи испытали это, другие - нет, но вполне можно сказать, что все предыдущие версии Firefox использовали гораздо больше памяти, чем текущую версию. Тем не менее, функциональность расширяется, и параметры добавляются. Я бы ожидал, что использование памяти увеличится в качестве дополнительных опций, и такие вещи будут добавлены.

Другими словами, должны быть методы, позволяющие убедиться, что ваша программа не использует память компьютера.

Итак, я превращаю это в вопрос «лучших практик», спрашивая всех вас, какие ваши маленькие трюки и трюки должны сделать вашу программу так, как она есть, с меньшим количеством процессора, чем вы обычно думали. А также, что, безусловно, избежать.

Немного вопрос-вопрос здесь: я пришел что-то в книге о C#. По-видимому, при кодировании Enum можно установить размер индекса этого Enum. С большой Enum, вы должны позволить компилятор справиться с этим я думаю, но для Enum который содержит только как 2 или 3 деталей, вы можете сделать это:

public enum HTMLTYPE : sbyte 
{ 
    HTML401,XHTML10,XHTML11 
} 

Для тех из вас, кто не знает, почему , по-видимому, объем памяти, зарезервированной для индекса любого Enum, автоматически устанавливается на целое число в C#. Другими словами, этот объем памяти будет зарезервирован. Но при определении столь маленьких вещей в вашем Enum целое число - это пустая трата пространства. В книге утверждалось, что это может сократить объем памяти, используемой программой. Мне интересно, правда ли это.

EDIT: действительно, это должна быть память, черт меня. Изменено все записи.

+0

Вы запутанным CPU и RAM (он же памяти)? –

+0

Таким образом, исправление утечек памяти имеет тенденцию помогать. :) – BobbyShaftoe

+0

@Bobby: Вы не можете «просачивать» память в C#. По крайней мере, в традиционном смысле, и пока вы не становитесь небезопасными. Однако вы можете протекать другими ресурсами. –

ответ

1

Существует хороший онлайн книга об этом:

http://www.cix.co.uk/~smallmemory/

+0

Больше недоступно; [this] (http://www.smallmemory.com/book.html) представляется одной и той же книгой. – CharlieHanson

2

Это правда, и это не так. Причина в том, что использование внутрипроцессорного процессора естественным образом (за исключением случаев, когда выполняется x64 Windows, то более естественным будет Int64). Это связано с тем, что в CPU у вас 4 регистра длиной 32 бит (или 64 бит в режиме x64).

Кроме того, давайте посмотрим правде в глаза: .NET не является чрезмерно об эффективности, как в памяти, так и в процессоре. Есть практика не совершать больших ошибок (например, конкатенация строк в цикле, а не с помощью StringBuilder), но перечисления, уменьшенные с 4 байтов до 1 байта, не стоят того.

+0

В общем, конечно, согласен. Однако для очень больших наборов данных может стоить 75% уменьшения размера хранилища. :) – BobbyShaftoe

+0

Uhm, no. Я разрабатываю ОЧЕНЬ большое приложение для страховой компании. Такая оптимизация для одного объекта milion даст ... 3 MB. И это может убить производительность. Так что лучше искать их где-то в другом месте. – Migol

8

Во-первых, вы, вероятно, путаете процессор и оперативную память (aka memory). CPU - это процессор, то есть то, что запускает ваш код против ваших данных. Память - это код и данные , хранящиеся.

Следует избегать этого перечисления. Во-первых, sbyte не соответствует CLS. Тогда это может ограничить будущее расширение. Всегда есть тот факт, что ЦП всегда использует целые слова (int в 32-битных архитектурах и long в 64-битных архитектурах). Вы теряете все это и за что выигрываете? Несколько байт от вашей памяти.

Подробнее, следуйте этим мудрым словам: Преждевременная оптимизация - это корень всего зла.

Это означает, что только оптимизация, когда это действительно необходимо. Сначала измерьте вещи. Вы, скорее всего, поймете, что это не те три байта из перечисления, которые нуждаются в сокращении.

+0

Я занимаюсь событием, хотя меня немного озадачивает еще одно цитирование всей вещи «Преждевременная оптимизация»! – BobbyShaftoe

5

Один из методов заключается в использовании lazy initialization для создания объектов только тогда, когда они вам понадобятся.

Кроме того, не забудьте уничтожить (или установить нулевые) объекты, которые вам больше не нужны, чтобы они могли собирать мусор.

2

Лучший способ сохранить память - сначала написать код чистым способом, чтобы вы могли видеть дизайн приложения в нем.

Затем создайте новую версию кода, которая изменена для памяти. Таким образом, вы уверены, что будущие версии не работают с обфускационным кодом.

И да, с лучшими воспоминаниями и процессорами, которые станут меньше, вы подумаете о таких оптимизациях.

2

Когда дело доходит до оптимизации, обычно лучше всего сосредоточиться на разработке алгоритма. Если вы по-прежнему не получите требуемую производительность, то пришло время выяснить микро-оптимизации.

Отказ от ответственности: оптимизация использования памяти не всегда может быть хорошей. К сожалению, много времени вы должны принимать решения о том, следует ли оптимизировать время (использование ЦП) или пространство (ОЗУ или дисковое пространство). Хотя иногда у вас может быть ваш торт и есть его тоже, это не всегда так просто.

Небольшой вопрос-вопрос здесь: я получил нечто похожее на книгу о C#. По-видимому, при кодировании Enum можно установить размер индекса этого Enum. С большой Enum, вы должны позволить компилятор справиться с этим я думаю, но для Enum который содержит только как 2 или 3 деталей, вы можете сделать это:

...

Для тех из вас, кто не t знаю, почему, по-видимому, объем памяти, зарезервированный для индекса любого Enum, автоматически устанавливается на целое число в C#. Другими словами, этот объем памяти будет зарезервирован. Но при определении столь маленьких вещей в вашем Enum целое число - это пустая трата пространства. В книге утверждалось, что это может сократить объем памяти, используемой программой. Мне интересно, правда ли это.

Я не уверен на 100% об этом, но это может не обязательно быть правдой. На самом деле, вероятно, не является true, если вы используете Mono и развертываете это приложение в других системах. Причина в том, что разные операционные системы и процессоры имеют разные требования к выравниванию памяти. Таким образом, несмотря на то, что вы объявляете его как sbyte, он может быть принужден к 32-битовому или 64-битовому целому к тому времени, когда он действительно войдет в память в любом случае (OS X особенно придирчив к выравниванию памяти).

Теперь я мог бы полностью упустить этот пункт здесь, и в этом случае книга могла быть абсолютно права. Но я хочу сказать, что «это немного сложнее, чем это», и указать, что такая оптимизация может быть не переносимой на другие платформы (разные ОС, процессоры и языки программирования).

+0

На самом деле, я бы сказал, что вы можете использовать свой торт и съесть его тоже. исключение времени-против-памяти-компромиссы; в большинстве случаев меньший объем памяти означает меньшее количество промахов в кеше и приводит к более быстрому выполнению (иногда это резко). –

2

Все это хорошие алгоритмические подходы к проблеме памяти, но на практике вы также хотите запустить свой код через профилировщик, чтобы узнать, где находятся ресурсы памяти и процессора.

Смежные вопросы