Память по сравнению с производительностью

Это зависит от

Задайте осязаемый вопрос!

РЕДАКТИРОВАТЬ: Если вы думаете о кэшировании на этапе проектирования, тогда вернитесь чтобы запустить и запустить его снова (кэширование всегда компромиссное решение)!

Это зависит от многих факторов. Что из двух будет ограничивать первым? Нужно ли запускать другие приложения на одном сервере? Что сложнее продлить?

Лучше думать об этом не абстрактно, а с точки зрения конкретного проекта.

1. Если у вас закончится оперативная память, вы пожалеете, так что сохраните структуру данных как можно более чистым и простым, даже если кажется, что вам, возможно, придется закодировать некоторые циклы, которые могут показаться неэффективными. Усложнение кода и структуры данных из-за проблем с производительностью - это суть преждевременной оптимизации. И хотя люди кричат ​​против преждевременной оптимизации и заявляют, что не делают этого, они все равно делают это до ужасающей степени.

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

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

What do your customers require?

You should have at least some idea of what platform your users will be running it on. You also need to have some idea of the performance requirements (transactions per second, or whatever). Produce some conservative estimates of the minimum spec platform you will require, then design to that.

You also seem to be a bit confused in your post - using less memory is not an end goal if the purpose is to use it for caching (i.e. you are actually using the memory saved to improve performance). In which case, go for whatever gives you most bang-per-developer-hour.

Вы можете думать о производительности с точки зрения пропускной способности и времени отклика. Найдите способы измерить эти два фактора и настроить тип нагрузки, с которой ваша система должна справиться и работать оттуда. Решения относительно памяти / времени обработки (то, что вы называете «производительностью») принимаются после того, как вы измерили свою пропускную способность / время отклика под нагрузкой. В общем, вы должны попытаться использовать как можно больше ЦП (чтобы получить максимальную пропускную способность), чтобы вы могли использовать всю доступную память.

Я думаю, вам следует поработать над достижением баланса между использованием памяти и процессора.

Если вы работаете над серверным компонентом, я бы побеспокоился о том, чтобы он работал с несколькими пользователями . Сколько пользователей может обслуживать ваше приложение? Можете ли вы привлечь больше пользователей, используя те же ресурсы?

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

• Если вы обрабатываете небольшие объемы данных за раз, вы можете оптимизировать производительность, предварительно выбирая следующие N фрагментов и тем самым увеличивая потребление памяти.
• Если ваши данные довольно большие, они могут довольно скоро полностью заполнить вашу основную память, и упреждающее чтение приведет к перебоям (например, упреждающее чтение вынуждает записывать данные обратно на диск / базу данных до того, как они будут полностью обработаны; тогда вам понадобятся эти данные обратно в память и тем самым принудительно поменять местами эти значения упреждающего чтения)

Итак, сначала получите рабочую версию вашего приложения. Затем выполните профилирование и посмотрите, в чем заключаются узкие места. (Преждевременная оптимизация - корень всех зол! - Дональд Э. Кнут)

Этот вопрос так же стар, как и само программирование. Ответ, к сожалению, «зависит от обстоятельств». Если вы пишете приложение для системы с 32 ГБ ОЗУ, и ваше программное обеспечение - единственное, что будет работать, вам следует написать свой код, чтобы воспользоваться этим. Если, с другой стороны, вы пишете код, который будет работать во встроенной системе, вам, вероятно, следует использовать как можно меньше памяти. НАИБОЛЕЕ важно, чтобы вы знали об этих компромиссах, профилировали свой код и оптимизировали самые большие узкие места.

Нет единственного правильного выбора - это зависит от вашего приложения и его требований. Тем не менее, это часто выбор одного или другого - вы не можете часто (если вообще когда-либо) максимизировать производительность и снизить потребление памяти. Если это какая-либо критическая система, максимальные границы для памяти и / или нижние границы производительности должны быть указаны заказчиком - если нет, они должны быть.

1. Заставьте это работать.

Вы получите разные ответы, и это, честно говоря, зависит от приложения. Нет однозначного ответа, охватывающего все случаи, кроме:

1. Заставить его работать.

Программное обеспечение можно переоценить.

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

It really depends on the kind of program. If you can control the target machines it makes it a bit easier. If you know that even at the extremes, you aren't going to run out of memory, then you ight as well use all you want. There is no advantage in memory not used by anything.

In general I think of things in several categories.

Supplemental programs, If the program is not performing the primary use of the machine then It should try and conserve memory, While not a server thing the examples I usually think of in this case are Desktop widgets and Tomboy.. They are not the primary use, so they shouldn't take too many resources away from the system, that could potentially impair the performance of the primary application.

General applications, These have simple priorities. Firstly do the job required, then if it's slow, make it faster. You shouldn't need to worry about memory too much unless you are being foolhardy (or using python or java :-) )

Many instance applications. If you expect the user to have many instances of the application either as multiple tasks or just multiple instances within the same task (like multiple firefox windows/tabs), Because things multiply you need to keep a handle on memory usage. Speed s not so much an issue of making operations faster as ensuring that idle instances are not actually doing any processing.

Jumbo applications, If your application actually has a huge task to perform, like say image manipulation, then you should consider memory usage from the outset. I suspect Evolution consumes a lot of ram (currently 142 meg on my machine) because they had a jumbo task but didn't realise it. I have a lot of email, mostly incoming from lists,

If you can control your target environment then you can just have as much ram as needed, It's easier for you. If other users are going to have your program then requiring more memory is still easier for you, but it's not friendly to the users.

I'm doing development on an OLPC XO, Largely trying to make the system nice with supplemental programs. That means I'm really focused on low memory usage, but even on a system that is that memory restricted I find that there is not much use in further reducing memory usage. After boot it has over 150 meg free. Which is enough to run all of the lightweight apps you want but most of the heavier apps will be a strain. There is very little middle ground. Further optimising a 2 meg app to only use one meg doesn't give you that much more elbowroom if you are running an app like firefox.

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

Затем профилируйте и устраните ваши фактические узкие места.

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