2008-11-15 2 views
0

При проектировании любых настольных приложений существуют ли общие правила о том, сколько памяти должно использовать приложение?Что представляет собой хороший профиль памяти?

Для тяжелых приложений они могут быть легко поняты или, по крайней мере, профилированы, например, Firefox или Google Chrome. Но для небольших утилит или бизнес-приложений, насколько приемлемый объем использования памяти?

Я спросил, потому что недавно я столкнулся с компромиссом между использованием памяти и производительностью и задаюсь вопросом, существует ли общее мнение относительно этого?

EDIT: Платформа Windows XP для пользователей с машиной, которая может работать только с богатыми интернет-приложениями.

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

Но что было бы хорошего числа? Как вы придумали? Это то, о чем я прошу.

+0

Возможно, вы могли бы опубликовать конкретный компромисс, с которым вы столкнулись? – 2008-11-15 19:23:47

+0

уточнил, спасибо! – chakrit 2008-11-15 20:14:24

ответ

2

Абсолютного ответа на этот вопрос нет. Это зависит от слишком большого числа переменных.

Вот некоторые компромиссы для рассмотрения:

  • Какого устройства/платформа Вы разрабатываете для?
  • Вы ожидаете, что ваш пользователь будет использовать это программное обеспечение в качестве основной цели для своего компьютера (например, возможно, вы разрабатываете какое-либо серверное программное обеспечение)
  • Кто ваша целевая аудитория, пользователи на дому? опытных пользователей?
  • Вы делаете реалистичные ожидания относительно объема оперативной памяти, которую пользователь получит?
  • Вы принимаете во внимание, что пользователь будет использовать много другого программного обеспечения на этом компьютере?

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

Я бы рекомендовал использовать больше оперативной памяти, чтобы получить лучшую скорость, если нужно. Но только если требования к ОЗУ реалистичны для вашей целевой аудитории. Например, если вы ожидаете, что домашний пользователь имеет 1 ГБ ОЗУ для использования вашей программы, тогда не используйте 600 МБ ОЗУ самостоятельно.

Рассмотрите возможность использования большего количества оперативной памяти в этом случае, чтобы получить лучшую скорость и оптимизировать часть другой части вашего кода, чтобы использовать меньше ОЗУ.

Edit:

О вашей конкретной ситуации кэширования изображений. Я думаю, вам было бы лучше, если бы вы разрешили пользователю устанавливать количество кэширования, которое они хотели бы выполнить в качестве опции. Таким образом, люди с большим количеством ОЗУ могут повысить его производительность, а люди с небольшой оперативной памятью могут снизить его.

0

Это зависит от оборудования вашего целевого ПК. Если ваше приложение использует слишком много памяти, оно будет медленным во время работы с окнами. КОНТРОЛЬНАЯ РАБОТА! Попробуйте оба варианта в вашем компромиссе, а некоторые между ними, если это имеет смысл. Запустите тесты на типичной машине, которую будут использовать ваши пользователи и с открытым количеством других приложений. Таким образом, для большинства людей это Outlook и, вероятно, экземпляр или 2 Internet Explorer (или почтовый клиент/браузер по вашему выбору). Я работаю в организме, где использование моего приложения также, вероятно, будет работать с некоторыми другими настраиваемыми приложениями, поэтому мы тестируем и те, которые работают. Мы обнаружили, что наше приложение использует слишком много памяти и делает приложение переключения болезненно медленным, поэтому мы немного замедлили наше приложение, чтобы уменьшить его использование памяти. Если вам интересно, наше целевое оборудование изначально было 512 Мб машин, потому что это была наша общая стандартная рабочая станция. Несколько ПК пришлось обновить до 1 Гб, хотя из-за этого приложения. Мы теперь немного обрезали его использование ОЗУ, но он написан на VB .NET, и большая часть используемой памяти, похоже, является основой. PerfMon говорит, что этот процесс использует aroung 200Mb (пик), но управляемая куча составляет всего около 2 Мб!

1

Это зависит полностью от целевой платформы, которая более или менее является бизнес-решением. Чем больше памяти вам понадобится, тем меньше клиентов сможет использовать ваше программное обеспечение. Некоторые вопросы: сколько памяти ваши клиенты (или потенциальные клиенты) установили на своих компьютерах? Какие другие приложения будут выполняться одновременно с вашим приложением? Предполагается ли, что ваше приложение работает исключительно (например, полноэкранная компьютерная игра) или утилита, которая должна работать в основном в фоновом режиме или часто переключается на нее из других приложений?

Hear является одним из примеров опроса, показывающий распределение установленной оперативной памяти в системах людей, играющих в игры через Steam (источник: Valve - Survey Summary Data):

  • Менее 96 Мб 0,01%
  • 96 Мб 127 Мб 0,01%
  • 128 Мб до 255 Мб 0,21%
  • 256 Мб до 511 Мб 5,33%
  • 512 Мб до 999 Мб 19,81%
  • 1 Гб до 1,49 ГБ 30,16%
  • 1.5 Гб до 1,99 Гб 6,10%
  • 2,0 Gb 38,37%

вывода, я хотел бы сделать из опроса, как это в моем домене (компьютерные игры), я могу разумно ожидать, почти все наши пользователей, имеющие 512 Мб или больше, и подавляющее большинство из них имеет 1 ГБ или больше. Для компьютерной игры, которая должна работать эксклюзивно, это означает, что рабочий набор около 400 МБ является достаточно безопасным и не будет ограничивать почти никого, и если он обеспечивает значительную добавленную стоимость для продукта, может иметь смысл иметь рабочий набор около 800 МБ.