Быстрее к malloc несколько маленьких раз или несколько больших раз?

Фактические документы стандартов не могут быть самыми полезными. Большинство компиляторов не полностью реализует стандарты и может иногда на самом деле конфликтовать. Таким образом, документация компилятора, которую Вы уже имели бы, будет более полезной. Кроме того, документация будет содержать определенные для платформы комментарии и примечания по любым протестам.

5
задан user21293 7 July 2009 в 19:14
поделиться

14 ответов

It depends:

  • Multiple small times means multiple times, which is slower
  • There may be a special/fast implementation for small allocations.

If I cared, I'd measure it! If I really cared a lot, and couldn't guess, then I might implement both, and measure at run-time on the target machine, and adapt accordingly.

In general I'd assume that fewer is better: but there are size and run-time library implementations such that a (sufficiently) large allocation will be delegated to the (relatively slow) O/S. whereas a (sufficiently) small allocation will be served from a (relatively quick) already-allocated heap.

20
ответ дан 18 December 2019 в 05:12
поделиться

Кроме проблем со скоростью существует также проблема фрагментации памяти .

4
ответ дан 18 December 2019 в 05:12
поделиться

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

1
ответ дан 18 December 2019 в 05:12
поделиться

Еще один момент, который следует учитывать, - это то, как это взаимодействует с потоками. Многократное использование malloc в многопоточном параллельном приложении существенно снижает производительность. В этой среде вам лучше использовать масштабируемый распределитель, подобный тому, который используется в Intel Thread Building Blocks или Hoard . Основное ограничение malloc состоит в том, что существует единственная глобальная блокировка, за которую борются все потоки. Это может быть настолько плохо, что добавление еще одного потока резко замедлит ваше приложение.

2
ответ дан 18 December 2019 в 05:12
поделиться

Allocating memory is work. The amount of work done when allocating a block of memory is typically independent of the size of the block. You work it out from here.

3
ответ дан 18 December 2019 в 05:12
поделиться

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

Вы можете использовать std :: vector для упрощения управления памятью (см. Процедуру std :: vector :: reserve). Примечание: зарезервированный, вероятно, выделит немного (возможно, в 2 раза) больше памяти, чем необходимо.

1
ответ дан 18 December 2019 в 05:12
поделиться

This question is one of pragmatism, I'm afraid; that is to say, it depends.

If you have a LOT of pixels, only a few of which are black then counting them might be the highest cost.

If you're using C++, which your tags suggest you are, I would strongly suggest using STL, somthing like std::vector.

The implementation of vector, if I remember correctly, uses a pragmatic approach to allocation. There are a few heuristics for allocation strategies, an informative one is this:

class SampleVector {
    int N,used,*data;
public:
    SampleVector() {N=1;used=0;data=malloc(N);}

    void push_back(int i)
    {
        if (used>=N)
        {
            // handle reallocation
            N*=2;
            data=realloc(data,N);
        }
        data[used++]=i;
    }
};

In this case, you DOUBLE the amount of memory allocated every time you realloc. Это означает, что частота перераспределения постепенно уменьшается вдвое.

Ваша реализация STL будет хорошо настроена, поэтому, если вы можете это использовать, сделайте!

2
ответ дан 18 December 2019 в 05:12
поделиться

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

5
ответ дан 18 December 2019 в 05:12
поделиться

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

14
ответ дан 18 December 2019 в 05:12
поделиться

In general malloc is expensive. It has to find an appropriate memory chunk from which to allocate memory and keep track of non-contiguous memory blocks. In several libraries you will find small memory allocators that try to minimize the impact by allocating a large block and managing the memory in the allocator.

Alexandrescu deals with the problem in 'Modern C++ Design' and in the Loki library if you want to take a look at one such libs.

2
ответ дан 18 December 2019 в 05:12
поделиться

«Я могу выделить все» (правда, могу!)

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

malloc должен быть общим. Он должен реализовывать всевозможные виды распределения. По этой причине он очень медленный! Может случиться так, что вы используете специальную суперсовременную библиотеку, которая ускоряет процесс, но они также не могут творить чудеса, поскольку они должны реализовать malloc во всем его спектре.

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

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

0
ответ дан 18 December 2019 в 05:12
поделиться

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

1
ответ дан 18 December 2019 в 05:12
поделиться

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

Описанный вами сценарий запрашивает предварительное выделение большого блока, imho.

1
ответ дан 18 December 2019 в 05:12
поделиться

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

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

3
ответ дан 18 December 2019 в 05:12
поделиться
Другие вопросы по тегам:

Похожие вопросы: