Тривиальные способы повышения производительности приложений

Question

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

1. Какой из них предпочитает динамическое/статическое распределение памяти, когда возможны оба варианта.
2. Скребок int и с использованием short или int8_t. Это действительно поможет? Или это будет скорее головной болью?
3. Динамическое распределение «пропорционально» большого объема памяти (из-за отсутствия информации о реальной памяти). И затем перераспределяя его на меньшую память (компактную) и удаляя первый. Например. Я выделяю 1000 единиц памяти. Затем, после вычисления, я определяю, что требуется только 400 единиц. Поэтому я выделяю новые 400 единиц, копирую 400 элементов, а затем удаляю 1000 единиц. В этом процессе я в конечном итоге выделяю еще больше памяти, например, 1400 единиц. Так должен ли я на самом деле приложить усилия, чтобы выделить новые 400 единиц и позволить 600 единиц отходов? [главный вопрос]
4. Любое эффективное использование union для уменьшения использования памяти?

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

Answer 1

2. Static. Don't allocate memory when you don't need to.

3. If the system is a 32-bit system, then the actual instructions to the processor will actually prefer uint32_t or int32_t...

5. If I need a generic data type that would need to be allocated several times in a loop, then a union can come in handy... to avoid allocating memory.

6. From my experience, allocating memory can be a slow process if it is done in a loop... You will see a performance increase if you allocate all the memory ahead of time, and then use it from a pool. When the system has go find huge blocks of memory, it can be a bottleneck.

7. In real-time situations with large chunks of memory... yes... otherwise... eh... not really

Надеется, что это помогает ... Если вы будете следовать этому стилю, вы заметите улучшенную производительность.

Answer 2

7. Действительно ли мои проблемы реальны?

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

Answer 3

Это, вероятно, намного лучше подходит для Programmers.StackExchange.com. Несмотря на это, я обычно следую философии unix, не фиксирую бутылку, пока вы ее не увидите.

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

Если вы заинтересованы, передайте -O3 в свой компилятор.