Поход в boost

[Igors]

Добрый день

Понадобился кастомный аллокатор чтобы не вызывать new/delete на каждый чих. Выглядит примерно так

Выделение эл-та(ов): напр нужно распределить 1 эл-т, а мы распределим сразу напр new[100] и вернем адрес на 1-й. Когда нужно распределить 2-й - new уже делать не будем а просто вернем адрес на 2-й (из 100) и.т.д пока не кончатся наши 100. А тогда опять new[100], т.е. новый блок

Удаление эл-та(ов): не освобождаем память, а связываем "удаленные" эл-ты в список с тем чтобы использовать их при следующих выделениях.

Однако все это становится не так уж просто если выделяется переменное число эл-тов. Да и вообще, с какой стати здесь "велосипедить"? Ведь задача самая что ни на есть стандартная. Решено: будем использовать "готовые проверенные решения"  

Да, но где ж его взять? Не помню такого ни в Qt ни в std. Ладно, надо искать а бусте (ведь круче нет, правда?).

Открываю Allocators, containers and memory allocation algorithms - ну а где ж искать как не здесь? И сразу получаю по рогам

Introduction to Interprocess allocators

Ни хрена не пойму - это что, все посвящено Interprocess? Но я никакого обмена между процессами не планировал..

Ладно, попробуем с др стороны pool_alloc - вроде по смыслу "оно", но тут какой-то мутекс, и где/откуда его брать хз. Ладно, как же его юзать? Гуглю "pool_alloc example" - ничего внятного.

Я понимаю что у каждой либы свои правила и не требую легкости Qt Assistant. Но что мне делать (или какие подходы использовать) чтобы "прикоснуться к великому"?  

[Пантер]

У буста херово с документацией, приходится гуглить постоянно.

[qate]

а чем плохо вызывать new и delete для каждого объекта ?

[Old]

а чем плохо вызывать new и delete для каждого объекта ?

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

[qate]

а чем плохо вызывать new и delete для каждого объекта ?

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

да, хотел этим вопросом чтобы ТС раскрыл понятие свое объекта, которых он хотел много и как часто new delete

[Igors]

да, хотел этим вопросом чтобы ТС раскрыл понятие свое объекта, которых он хотел много и как часто new delete

Вот сейчас читаю. Хорошо пишут. См Dynamic memory allocation is often inefficient

[Racheengel]

а чем плохо вызывать new и delete для каждого объекта ?

1. быстродействие
2. риск фрагментации памяти

[qate]

а чем плохо вызывать new и delete для каждого объекта ?

1. быстродействие
2. риск фрагментации памяти

1. зависит от объекта: если много действий в конструкторе и деструкторе, то быстродействие не страдает
2. тут не скажу, надо бы изучить вопрос подробнее

[Racheengel]

1. зависит от объекта: если много действий в конструкторе и деструкторе, то быстродействие не страдает

То есть как это?
Вот, допустим, new занимает N времени, остальной конструктор дополнительно M времени, соответственно общее время конструктора N+M. Для X объектов время будет X*N + X*M, т.е. в любом случае затраты на new мультиплицируются.

Конечно, все зависит от того, как часто объекты создаются, но здесь то речь как раз о том, что "очень часто". И тогда это критично - иначе бы люди не делали пулов

[qate]

1. зависит от объекта: если много действий в конструкторе и деструкторе, то быстродействие не страдает

То есть как это?

имел ввиду, что время new значительно меньше конструктора\деструктора, не забываем также что свой new также будет время занимать )
думаю, что писать свой пул - это надо иметь веские причины и тесты, что стандартный работает плохо, а свой велосипед лучше
без тестов "до" и "после" - все это ради разговора только

[Igors]

имел ввиду, что время new значительно меньше конструктора\деструктора, не забываем также что свой new также будет время занимать )
думаю, что писать свой пул - это надо иметь веские причины и тесты, что стандартный работает плохо, а свой велосипед лучше
без тестов "до" и "после" - все это ради разговора только

Что ж Вы так недоброжелательно (или даже агрессивно) относитесь к незнакомым вещам Пройти по ссылке наверно было тяжко, ну ладно, приведу здесь

Dynamic memory allocation is often inefficient

Because of the complication of dynamic memory allocation, it is often inefficient in terms of time and/or space. Most memory allocation algorithms store some form of information with each memory block, either the block size or some relational information, such as its position in the internal tree or list structure. It is common for such header fields to take up one machine word in a block that is being used by the program. The obvious disadvantage, then, is when small objects are dynamically allocated. For example, if ints were dynamically allocated, then automatically the algorithm will reserve space for the header fields as well, and we end up with a 50% waste of memory. Of course, this is a worst-case scenario. However, more modern programs are making use of small objects on the heap; and that is making this problem more and more apparent. Wilson et. al. state that an average-case memory overhead is about ten to twenty percent2. This memory overhead will grow higher as more programs use more smaller objects. It is this memory overhead that brings programs closer to the virtual limit.

In larger systems, the memory overhead is not as big of a problem (compared to the amount of time it would take to work around it), and thus is often ignored. However, there are situations where many allocations and/or deallocations of smaller objects are taking place as part of a time-critical algorithm, and in these situations, the system-supplied memory allocator is often too slow.

Да, и про скорость я разговора не начинал, получил серьезный перерасход памяти в той самой ситуации "мелкого но много". И о написании своего пула речь не идет, вопрос где такой готовый.

[qate]

Что ж Вы так недоброжелательно (или даже агрессивно) относитесь к незнакомым вещам

это не агрессия, а опыт тестирования )
есть баг или медленная работа - фиксируем, исправляем, проверяем теже действия
нужна новая фича в распределении памяти, а был ли баг или медленная работа ?

[Igors]

это не агрессия, а опыт тестирования )

Наверное "богатый" (опыт-то) 

есть баг или медленная работа - фиксируем, исправляем, проверяем теже действия

Вы как-то все время "даете рекомендации", и я прям теряюсь, как же их выполнять? 

нужна новая фича в распределении памяти, а был ли баг или медленная работа ?

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