|
Название: Поход в boost Отправлено: Igors от Сентябрь 27, 2015, 08:12 Добрый день
Понадобился кастомный аллокатор чтобы не вызывать new/delete на каждый чих. Выглядит примерно так Цитировать Выделение эл-та(ов): напр нужно распределить 1 эл-т, а мы распределим сразу напр new[100] и вернем адрес на 1-й. Когда нужно распределить 2-й - new уже делать не будем а просто вернем адрес на 2-й (из 100) и.т.д пока не кончатся наши 100. А тогда опять new[100], т.е. новый блок Однако все это становится не так уж просто если выделяется переменное число эл-тов. Да и вообще, с какой стати здесь "велосипедить"? Ведь задача самая что ни на есть стандартная. Решено: будем использовать "готовые проверенные решения" :)Удаление эл-та(ов): не освобождаем память, а связываем "удаленные" эл-ты в список с тем чтобы использовать их при следующих выделениях. Да, но где ж его взять? Не помню такого ни в Qt ни в std. Ладно, надо искать а бусте (ведь круче нет, правда?). Открываю Allocators, containers and memory allocation algorithms (http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/allocators_containers.html) - ну а где ж искать как не здесь? И сразу получаю по рогам Цитировать Introduction to Interprocess allocators Ни хрена не пойму - это что, все посвящено Interprocess? Но я никакого обмена между процессами не планировал..Ладно, попробуем с др стороны pool_alloc (http://www.boost.org/doc/libs/1_33_1/libs/pool/doc/implementation/pool_alloc.html) - вроде по смыслу "оно", но тут какой-то мутекс, и где/откуда его брать хз. Ладно, как же его юзать? Гуглю "pool_alloc example" - ничего внятного. Я понимаю что у каждой либы свои правила и не требую легкости Qt Assistant. Но что мне делать (или какие подходы использовать) чтобы "прикоснуться к великому"? :) Название: Re: Поход в boost Отправлено: Пантер от Сентябрь 27, 2015, 12:34 У буста херово с документацией, приходится гуглить постоянно.
Название: Re: Поход в boost Отправлено: qate от Сентябрь 28, 2015, 09:30 а чем плохо вызывать new и delete для каждого объекта ?
Название: Re: Поход в boost Отправлено: Old от Сентябрь 28, 2015, 09:44 а чем плохо вызывать new и delete для каждого объекта ? Это абстрактный вопрос. Все зависит от того, что используется под капотом этих операторов.Название: Re: Поход в boost Отправлено: qate от Сентябрь 28, 2015, 10:11 а чем плохо вызывать new и delete для каждого объекта ? Это абстрактный вопрос. Все зависит от того, что используется под капотом этих операторов.да, хотел этим вопросом чтобы ТС раскрыл понятие свое объекта, которых он хотел много и как часто new delete Название: Re: Поход в boost Отправлено: Igors от Сентябрь 28, 2015, 10:44 да, хотел этим вопросом чтобы ТС раскрыл понятие свое объекта, которых он хотел много и как часто new delete Вот сейчас читаю (http://www.boost.org/doc/libs/1_59_0/libs/pool/doc/html/boost_pool/pool/pooling.html#boost_pool.pool.pooling.simple). Хорошо пишут. См Dynamic memory allocation is often inefficientНазвание: Re: Поход в boost Отправлено: Racheengel от Сентябрь 28, 2015, 11:12 а чем плохо вызывать new и delete для каждого объекта ? 1. быстродействие 2. риск фрагментации памяти Название: Re: Поход в boost Отправлено: qate от Сентябрь 28, 2015, 11:28 а чем плохо вызывать new и delete для каждого объекта ? 1. быстродействие 2. риск фрагментации памяти 1. зависит от объекта: если много действий в конструкторе и деструкторе, то быстродействие не страдает 2. тут не скажу, надо бы изучить вопрос подробнее Название: Re: Поход в boost Отправлено: Racheengel от Сентябрь 28, 2015, 11:39 1. зависит от объекта: если много действий в конструкторе и деструкторе, то быстродействие не страдает То есть как это? :) Вот, допустим, new занимает N времени, остальной конструктор дополнительно M времени, соответственно общее время конструктора N+M. Для X объектов время будет X*N + X*M, т.е. в любом случае затраты на new мультиплицируются. Конечно, все зависит от того, как часто объекты создаются, но здесь то речь как раз о том, что "очень часто". И тогда это критично - иначе бы люди не делали пулов :) Название: Re: Поход в boost Отправлено: qate от Сентябрь 28, 2015, 12:25 1. зависит от объекта: если много действий в конструкторе и деструкторе, то быстродействие не страдает То есть как это? :) имел ввиду, что время new значительно меньше конструктора\деструктора, не забываем также что свой new также будет время занимать ) думаю, что писать свой пул - это надо иметь веские причины и тесты, что стандартный работает плохо, а свой велосипед лучше без тестов "до" и "после" - все это ради разговора только Название: Re: Поход в boost Отправлено: Igors от Сентябрь 28, 2015, 12:58 имел ввиду, что время 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. Название: Re: Поход в boost Отправлено: qate от Сентябрь 28, 2015, 14:34 Что ж Вы так недоброжелательно (или даже агрессивно) относитесь к незнакомым вещам :) это не агрессия, а опыт тестирования ) есть баг или медленная работа - фиксируем, исправляем, проверяем теже действия нужна новая фича в распределении памяти, а был ли баг или медленная работа ? Название: Re: Поход в boost Отправлено: Igors от Сентябрь 28, 2015, 14:59 это не агрессия, а опыт тестирования ) Наверное "богатый" (опыт-то) :)есть баг или медленная работа - фиксируем, исправляем, проверяем теже действия Вы как-то все время "даете рекомендации", и я прям теряюсь, как же их выполнять? :)нужна новая фича в распределении памяти, а был ли баг или медленная работа ? Про скорость Вы начали разговор, а моя проблема - жрется много памяти, ну и на слабой машине уходит в свапы и.т.п. Где съедается память - недавно обсуждали |