Здравствуйте, TailWind, Вы писали:
TW>Стоит ли беспокоиться об этом?
следует беспокоиться тогда, когда вы измерите фрагментацию памяти
если есть возможность без ущерба коду избежать доп. динамических выделений памяти, то избегайте их (это и на перформанс и фрагментацию влияет положительно)
но не портите код ради виртуального выигрыша "нефрагментированной памяти"
Re[2]: Частое выделение памяти - стоит ли этого бояться?
Здравствуйте, R.O. Prokopiev, Вы писали:
ROP>Где?
я так понимаю, что на каждой итерации создается вектор, который выделяет динамическую память для хранения 10 элементов (ведь не на стеке же он это делает)
Re: Частое выделение памяти - стоит ли этого бояться?
Здравствуйте, TailWind, Вы писали:
TW>Где-то я читал, что если часто выделять и освобождать память, то она фрагменитруется и это может привести к плохим последствиям.
TW>Стоит ли беспокоиться об этом?
TW>Блок схема:
TW>
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, R.O. Prokopiev, Вы писали: ROP>>Где? U>я так понимаю, что на каждой итерации создается вектор, который выделяет динамическую память для хранения 10 элементов (ведь не на стеке же он это делает)
Емел в виду обещанную блок-схему. Где она?
Re[2]: Частое выделение памяти - стоит ли этого бояться?
вместо одной строчки во внутреннем скоупе вы написали 4 новых, причем увеличили скоуп жизни переменной
имхо, в данном случае пострадало качество кода и этого следует избегать
Re[2]: Частое выделение памяти - стоит ли этого бояться?
__>>Типа того...
U>вместо одной строчки во внутреннем скоупе вы написали 4 новых, причем увеличили скоуп жизни переменной U>имхо, в данном случае пострадало качество кода и этого следует избегать
Вынесение инварианта (а в исходном примере кол-во выделяемых элементов на каждой итерации постоянно) за пределы цикла вполне оправданное действие.
Многократных выделений/освобождений памяти удалось избежать.
_____________________
С уважением,
Stanislav V. Zudin
Re[3]: Частое выделение памяти - стоит ли этого бояться?
это очень интересный вопрос. честно скажу, что сам никогда не измерял степень фрагментации
приведу субъективные доводы:
с понятием фрагментация и ее причинами можно ознакомиться в гугле
например, http://dvoika.net/infor/teor/Glava%204/Index3.htm http://blog.pavlov.net/2007/11/10/memory-fragmentation/
TW>Как измерить фрагментацию?
это вроде не очень сложно, ибо есть соответствующие программулины, которые для вашего приложения могут показать картинку выделенных и неиспользуемых блоков памяти. тем самым фрагментация показывает неэффективность использования памяти. количественные меры тоже могут быть разными, например, отношение неиспользуемых блоков памяти к общей выделенной памяти для приложения
TW>Как измерить ущерб от фрагментации?
этот вопрос посложнее, ибо это скорее всего зависит от многих факторов
ущерб может быть вызван захватом излишней памяти у системы, либо замедление функция аллокации\деаллокации фрагментов памяти
отмечу, что отсутствие фрагментации памяти не гарантирует вам отсутствие "ущерба" ибо это тоже может негативно повлиять на перформанс приложения
проще всего действовать так:
мониторить объем поглощаемой памяти вашим приложением, если объем в разумных пределах, то улучшать ничего не надо
в противном случае можно поискать участки кода, аллоцирующие крупные куски памяти. возможно, там можно изменить логику и аллоцировать блоки по-меньше
если скорость работы хочется улушить, то натравить профайлер, посмотреть узкие места, потюнить их
в последнюю очередь уже можно исследовать аллокации, уменьшать их количество, вставлять собственные аллокаторы (например, аллокаторы маленьких объектов). наблюдать, повлияло ли это положительно на перформанс. если нет, то можно вернуть нормальный код назад
успехов
Re[3]: Частое выделение памяти - стоит ли этого бояться?
Здравствуйте, uzhas, Вы писали:
U>это вроде не очень сложно, ибо есть соответствующие программулины, которые для вашего приложения могут показать картинку выделенных и неиспользуемых блоков памяти. тем самым фрагментация показывает неэффективность использования памяти. количественные меры тоже могут быть разными, например, отношение неиспользуемых блоков памяти к общей выделенной памяти для приложения
Для Windows есть HeapWalk.
With best regards
Pavel Dvorkin
Re[4]: Частое выделение памяти - стоит ли этого бояться?
Здравствуйте, uzhas, Вы писали:
U>вместо одной строчки во внутреннем скоупе вы написали 4 новых, причем увеличили скоуп жизни переменной U>имхо, в данном случае пострадало качество кода и этого следует избегать
Про скоуп согласен, но это легко лечится, если приспичит.
Если в целом по качеству конкретного куска кода — то большой вопрос, на фига тут вообще vector
Ну а строчки мерить — занятие более бесполезное, чем борьба с фрагментацией.
Re[5]: Частое выделение памяти - стоит ли этого бояться?
Здравствуйте, Dzirt2005, Вы писали:
D>Как раз практически одно и тоже — количество выделений/освобождений блоков памяти если и будет отличаться, то на неуловимую величину.
Сильно зависит от реализации и от того, что еще происходит в данном конкретном приложении. Очень не советую надеяться на удачу. Будет не лень — попозже расскажу страшную историю
Re[4]: Частое выделение памяти - стоит ли этого бояться?
__>>>Типа того...
U>>вместо одной строчки во внутреннем скоупе вы написали 4 новых, причем увеличили скоуп жизни переменной U>>имхо, в данном случае пострадало качество кода и этого следует избегать
SVZ>Вынесение инварианта (а в исходном примере кол-во выделяемых элементов на каждой итерации постоянно) за пределы цикла вполне оправданное действие. SVZ>Многократных выделений/освобождений памяти удалось избежать.
Это ничего что освобождение и выделение памяти происходит именно в функциях clear() и resize() совершенно аналогично тому, как в исходом примере делалось то же самое происходило в конструкторе и деструкторе?
Re[6]: Частое выделение памяти - стоит ли этого бояться?
Здравствуйте, _stun_, Вы писали:
__>Здравствуйте, Dzirt2005, Вы писали:
__>Сильно зависит от реализации и от того, что еще происходит в данном конкретном приложении. Очень не советую надеяться на удачу. Будет не лень — попозже расскажу страшную историю
А я не надеюсь... Я на исходный код vector'а посмотрел. В отличие от некоторых ленивых, которые строят предположения на кем-то рассказанных страшных историях Функция vector::clear() освобождает выделенную память и длина vector'а становится равной нулю. Поэтому если бы мне нужно было что-то типа такого кода я бы сразу избавился от claer(), а при постоянной длине и от resize(). Или вызывал бы resize только при необходимости увеличить буфер и увеличивал бы его с запасом. При этом количество выделений памяти было бы существенно меньше, а общее ее потребление осталось таким же как и было в первоначальном алгоритме. Если пренебречь фрагментацией кучи естественно
Re[7]: Частое выделение памяти - стоит ли этого бояться?
выделений/освобождений памяти удалось избежать.
D>Это ничего что освобождение и выделение памяти происходит именно в функциях clear() и resize() совершенно аналогично тому, как в исходом примере делалось то же самое происходило в конструкторе и деструкторе?
Вас уже выше спросили, в какой это реализации stl так злобно начихали на reserve() ?
Re[8]: Частое выделение памяти - стоит ли этого бояться?
Здравствуйте, Ytz, Вы писали:
Ytz>Здравствуйте, Dzirt2005, Вы писали:
D>>А я не надеюсь... Я на исходный код vector'а посмотрел.
Ytz>Какая реализация STL? По моему опыту как раз освобождения памяти не происходит, недаром даже идиома горячей усадки существует.
Очень-очень старая Hewlett-Packard'овская, шедшая с одним из компиляторов Borland C++ под DOS. А что?
Может они таким образом память экономили, а может просто не подумали еще в то время... Я поискал еще по загашникам, нашел от Borland C++ 5.02. В этом варианте такие строки:
...
/* $Revision: 8.1 $ */
/***************************************************************************
*
* vector - declarations for the Standard Library vector class
*
* $Id: vector,v 1.41 1995/09/14 23:53:38 lijewski Exp $
*
***************************************************************************
*
* Copyright (c) 1994
* Hewlett-Packard Company
...
и, кстати, в этой реализации даже функции clear нет, но вызов erase( begin(), end() ); освобождения памяти не делает.
Это одна из иллюстраций того, что написал _stun_:
__>Сильно зависит от реализации ...
И именно потому я и написал, что вообще бы не надеялся на реализацию и выбросил бы вообще clear и reserve из цикла. Будем считать, что я вас немного подколол. Наверняка во всех современных реализациях такого нет, раз уже в 95 году не было.
Re[6]: Частое выделение памяти - стоит ли этого бояться?
Здравствуйте, _stun_, Вы писали:
__>Здравствуйте, Dzirt2005, Вы писали:
__>Вас уже выше спросили, в какой это реализации stl так злобно начихали на reserve() ?
Я там ответил...
Re[9]: Частое выделение памяти - стоит ли этого бояться?