Вы когда-нибудь получали значительное ускорение, используя boost :: pool?

Question

Я несколько раз играл с boost :: pool в тех местах, где мне показалось, что я серьезно забивал кучу большим количеством "оттока" объектов. Обычно я использовал boost::object_pool или boost::pool_alloc в качестве параметра шаблона STL. Однако результатом является то, что производительность практически не изменяется или значительно ухудшается.

Мне любопытно слышать о каких-либо историях успеха с ним.

Какие вещи я должен искать в выводе профилирования, что может означать, что boost :: pool может помочь?

Неужели на самом деле довольно сложно улучшить старый добрый malloc?

Answer 1

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

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

Answer 2

Да, увеличение скорости на 500%. Приложение (довольно глупо, но иногда вам приходится работать с тем, что вы получили) скопировало элементы из 1 std :: map в другой в цикле (в цикле было какое-то принятие решения), и результирующие распределения на многопоточных / процессных серверах привели к куче разногласий. Я добавил пул повышения в качестве распределителя на второй карте, и в результате скорость выполнения приложения увеличилась на 500%.

Answer 3

Слепые оптимизации не годятся. Попробуйте использовать распределитель памяти Google, вам даже не нужно перекомпилировать приложение. Здесь вы можете найти то, что вам нужно знать:

http://google -perftools.googlecode.com / SVN / багажник / док / tcmalloc.html

Гаэтано

Answer 4

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

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