Инструкции по Производительности/оптимизации памяти C++

общедоступные, защищенные и частные ключевые слова, вообще не помещаются в объектные файлы, поэтому есть никакой пользы.

В целом

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

На самом деле, в отличие от Java, при программировании на C ++ всегда нужно думать об управлении памятью, чтобы избежать утечек. Поэтому оптимизация происходит более естественно, чем, скажем, Java

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

Нет. AFAIK, неверумные методы не увеличивают размер экземпляра класса.

Есть ли у кого-нибудь ресурс для рекомендаций по оптимизации памяти C++?

1) Если вы беспокоитесь о производительности, используйте профилировщик (например, AQtime). Не угадывайте, используйте инструменты.
2) В общем, не очень хорошая идея часто (несколько _millions_ раз в секунду) выделять и освободить память (используя new/delete), особенно большие блоки. По моему опыту такое использование приводит к потере производительности. Если вам часто нужно выделить большой блок памяти с помощью одной и той же процедуры (с помощью new или std::vector), рассмотрите возможность повторного использования того же блока в следующем вызове (это будет сложно в многопоточном приложении). Т.е. вместо

void doStuff(int memSize){
    std::vector<char> buf(memSize);
    //..some code here
}

используйте что-то вроде этого:

void doStuff(int memSize){
    static std::vector<char> buf;
    if (buf.size() < memSize)
        buf.resize(memSize);
    //..some code here
}

Но только при необходимости и только в том случае, если вы абсолютно уверены, что эта процедура не может быть вызвана из нескольких отдельных потоков одновременно. (Чтобы сделать его многопоточным, вам понадобятся некоторые трюки - либо мьютексы, либо "пул" из нескольких буферов)
3) Выделение более 1 мегабайта (для Windows) или 8 мегабайт (для Linux) в стеке приведет к сбою вашей программы (переполнение стека для win, segfault в linux), если вы не указали размер стека во время компиляции. Пример:

void doStuff(){
    char buf[1024*1024*12];//use new[] or std::vector instead of this.
    //some code here
}

Это все, что я могу придумать.

Там есть « Эффективный C ++: методы программирования производительности » Дова Булки и Дэвида Мэйхью. Я не думаю, что это новаторский, но это определенно интересное чтение, которое учит некоторым основам.

Есть ли у кого-нибудь ресурс для руководства по оптимизации памяти в C++? Лучшие практики, настройка и т.д.?

Это во многом зависит от вашего компилятора и целевой среды (RISC, Unix/Linux, Windows). Большинство компиляторов имеют такую информацию.

Существуют утилиты, позволяющие отслеживать утечки памяти, чтобы вы могли устранить их во время тестирования. Если вы собираетесь динамически выделять много объектов (что обычно происходит в C/C++), постарайтесь убедиться, что вы все деаллоцируете перед уничтожением объекта. Для этого:

• Если вам важнее память, чем процессор, используйте умные указатели.
• Если в вашем классе есть переменные-члены, которые являются указателями, убедитесь, что ваш деструктор освобождает каждую из них. Группируйте переменные-члены вместе в исходном коде, чтобы было легко сопоставить эти переменные с деструктором.
• По возможности избегайте динамического выделения памяти, чтобы избежать утечек. Предпочитайте std::string вместо динамически выделяемых char* и т.д.

Будет ли какая-либо польза от компилятор или распределение памяти, чтобы избавиться избавиться от protected и private, поскольку поскольку в этом классе нет элементов, которые были бы protected и private в этом классе?

Нет, если я не ошибаюсь, protected/private проверяются только во время компиляции, поэтому они не влияют на производительность, даже если бы под этими ключевыми словами были элементы.

Кроме того, важно понимать, что компилятор очень интеллектуален (обычно больше, чем программист), поэтому он оптимизирует все, что может; например, давайте объявим переменную, int a, внутри вашего конструктора. И, допустим, вы не используете ее вообще, вы просто забыли ее там. Большинство компиляторов даже не сохранят место в стеке для этих переменных. Другие потребуют от пользователя включить оптимизацию, чтобы это произошло, но, как правило, производственная версия любой программы должна быть скомпилирована с включенной оптимизацией, даже если она не включена полностью.

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

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

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

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

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

Не должно быть разницы в использовании памяти.

Помимо этого, единственное преимущество, о котором я могу думать, это то, что кому-то, читающему код, придется иметь дело с меньшими трудностями (не то чтобы в вашем примере это было особенно обременительно).

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

• Оптимизация для повторного использования кеша (блокировка кеша, заполнение и т. д.)
• Оптимизация для минимизации попаданий TLB (сбои страниц)
• Организуйте свои данные как структуры массивов, а не как массивы структур
• Избегайте ненужной очистки памяти
• Избегайте перераспределения памяти попробуйте использовать вместо этого повторно

. Если вам нужно иметь много мелких объектов, обратите внимание на такие вещи, как шаблон проектирования легкого веса или пулы объектов.

Что касается объявлений private и protected , не беспокойтесь. Они актуальны только для компиляции, чтобы обеспечить инкапсуляцию и скрытие данных, и не влияют на сгенерированный двоичный файл.