Re[9]: Частое выделение памяти - стоит ли этого бояться?
От: _stun_ Россия  
Дата: 29.04.10 18:27
Оценка: +3 :)
Здравствуйте, Dzirt2005, Вы писали:

D>Очень-очень старая Hewlett-Packard'овская, шедшая с одним из компиляторов Borland C++ под DOS. А что?


Я, в принципе, и так понял, что Вы ответите.
Да ничего. Просто, строго говоря, это не C++ и не STL.
Re: Частое выделение памяти - стоит ли этого бояться?
От: uzhas Ниоткуда  
Дата: 29.04.10 13:06
Оценка: +2
Здравствуйте, TailWind, Вы писали:

TW>Стоит ли беспокоиться об этом?


следует беспокоиться тогда, когда вы измерите фрагментацию памяти
если есть возможность без ущерба коду избежать доп. динамических выделений памяти, то избегайте их (это и на перформанс и фрагментацию влияет положительно)
но не портите код ради виртуального выигрыша "нефрагментированной памяти"
Re[2]: Частое выделение памяти - стоит ли этого бояться?
От: uzhas Ниоткуда  
Дата: 29.04.10 13:26
Оценка: :))
Здравствуйте, _stun_, Вы писали:

__>Ну, в общем-то стоит.


__>
__>vector<ULONG> v;
__>v.reserve(10);
__>for (ULONG i=0; i<1000000; i++)
__>{
__>  v.clear();
__>  v.resize(10);
__>  ...
__>}
__>


__>Типа того...


вместо одной строчки во внутреннем скоупе вы написали 4 новых, причем увеличили скоуп жизни переменной
имхо, в данном случае пострадало качество кода и этого следует избегать
Re: Частое выделение памяти - стоит ли этого бояться?
От: _stun_ Россия  
Дата: 29.04.10 13:09
Оценка: +1
Здравствуйте, TailWind, Вы писали:

TW>Где-то я читал, что если часто выделять и освобождать память, то она фрагменитруется и это может привести к плохим последствиям.


TW>Стоит ли беспокоиться об этом?


TW>Блок схема:


TW>
TW>for (ULONG i=0; i<1000000; i++)
TW>{
TW>  vector<ULONG> v(10);
TW>  ...
TW>}
TW>


Ну, в общем-то стоит.

vector<ULONG> v;
v.reserve(10);
for (ULONG i=0; i<1000000; i++)
{
  v.clear();
  v.resize(10);
  ...
}


Типа того...
Re[3]: Частое выделение памяти - стоит ли этого бояться?
От: Stanislav V. Zudin Россия  
Дата: 29.04.10 14:08
Оценка: +1
Здравствуйте, uzhas, Вы писали:

__>>
__>>vector<ULONG> v;
__>>v.reserve(10);
__>>for (ULONG i=0; i<1000000; i++)
__>>{
__>>  v.clear();
__>>  v.resize(10);
__>>  ...
__>>}
__>>


__>>Типа того...


U>вместо одной строчки во внутреннем скоупе вы написали 4 новых, причем увеличили скоуп жизни переменной

U>имхо, в данном случае пострадало качество кода и этого следует избегать

Вынесение инварианта (а в исходном примере кол-во выделяемых элементов на каждой итерации постоянно) за пределы цикла вполне оправданное действие.
Многократных выделений/освобождений памяти удалось избежать.
_____________________
С уважением,
Stanislav V. Zudin
Re[3]: Частое выделение памяти - стоит ли этого бояться?
От: _stun_ Россия  
Дата: 29.04.10 16:35
Оценка: +1
Здравствуйте, Dzirt2005, Вы писали:


D>Типа это не одно и то же с точки зрения поставленного вопроса?


Да типа нет.
Re[4]: Частое выделение памяти - стоит ли этого бояться?
От: Dzirt2005  
Дата: 29.04.10 16:46
Оценка: -1
Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, uzhas, Вы писали:


__>>>
__>>>vector<ULONG> v;
__>>>v.reserve(10);
__>>>for (ULONG i=0; i<1000000; i++)
__>>>{
__>>>  v.clear();
__>>>  v.resize(10);
__>>>  ...
__>>>}
__>>>


__>>>Типа того...


U>>вместо одной строчки во внутреннем скоупе вы написали 4 новых, причем увеличили скоуп жизни переменной

U>>имхо, в данном случае пострадало качество кода и этого следует избегать

SVZ>Вынесение инварианта (а в исходном примере кол-во выделяемых элементов на каждой итерации постоянно) за пределы цикла вполне оправданное действие.

SVZ>Многократных выделений/освобождений памяти удалось избежать.

Это ничего что освобождение и выделение памяти происходит именно в функциях clear() и resize() совершенно аналогично тому, как в исходом примере делалось то же самое происходило в конструкторе и деструкторе?
Частое выделение памяти - стоит ли этого бояться?
От: TailWind  
Дата: 29.04.10 13:01
Оценка:
Где-то я читал, что если часто выделять и освобождать память, то она фрагменитруется и это может привести к плохим последствиям.

Стоит ли беспокоиться об этом?

Блок схема:

for (ULONG i=0; i<1000000; i++)
{
  vector<ULONG> v(10);
  ...
}
Re: Частое выделение памяти - стоит ли этого бояться?
От: R.O. Prokopiev Россия http://127.0.0.1/
Дата: 29.04.10 13:04
Оценка:
Здравствуйте, TailWind, Вы писали:

TW>Блок схема:

TW>
TW>for (ULONG i=0; i<1000000; i++)
TW>{
TW>  vector<ULONG> v(10);
TW>  ...
TW>}
TW>

Где?
Re[2]: Частое выделение памяти - стоит ли этого бояться?
От: uzhas Ниоткуда  
Дата: 29.04.10 13:09
Оценка:
Здравствуйте, R.O. Prokopiev, Вы писали:

ROP>Где?

я так понимаю, что на каждой итерации создается вектор, который выделяет динамическую память для хранения 10 элементов (ведь не на стеке же он это делает)
Re[3]: Частое выделение памяти - стоит ли этого бояться?
От: R.O. Prokopiev Россия http://127.0.0.1/
Дата: 29.04.10 13:13
Оценка:
Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, R.O. Prokopiev, Вы писали:

ROP>>Где?
U>я так понимаю, что на каждой итерации создается вектор, который выделяет динамическую память для хранения 10 элементов (ведь не на стеке же он это делает)
Емел в виду обещанную блок-схему. Где она?
Re[2]: Частое выделение памяти - стоит ли этого бояться?
От: Dzirt2005  
Дата: 29.04.10 13:25
Оценка:
Здравствуйте, _stun_, Вы писали:

__>Ну, в общем-то стоит.


__>
__>vector<ULONG> v;
__>v.reserve(10);
__>for (ULONG i=0; i<1000000; i++)
__>{
__>  v.clear();
__>  v.resize(10);
__>  ...
__>}
__>


__>Типа того...


Типа это не одно и то же с точки зрения поставленного вопроса?
Re[2]: Частое выделение памяти - стоит ли этого бояться?
От: TailWind  
Дата: 29.04.10 13:49
Оценка:
U>следует беспокоиться тогда, когда вы измерите фрагментацию памяти
Как измерить фрагментацию?
Как измерить ущерб от фрагментации?
Re[3]: Частое выделение памяти - стоит ли этого бояться?
От: uzhas Ниоткуда  
Дата: 29.04.10 14:16
Оценка:
это очень интересный вопрос. честно скажу, что сам никогда не измерял степень фрагментации
приведу субъективные доводы:
с понятием фрагментация и ее причинами можно ознакомиться в гугле
например, http://dvoika.net/infor/teor/Glava%204/Index3.htm
http://blog.pavlov.net/2007/11/10/memory-fragmentation/

TW>Как измерить фрагментацию?

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

TW>Как измерить ущерб от фрагментации?

этот вопрос посложнее, ибо это скорее всего зависит от многих факторов
ущерб может быть вызван захватом излишней памяти у системы, либо замедление функция аллокации\деаллокации фрагментов памяти
отмечу, что отсутствие фрагментации памяти не гарантирует вам отсутствие "ущерба" ибо это тоже может негативно повлиять на перформанс приложения
проще всего действовать так:

успехов
Re[4]: Частое выделение памяти - стоит ли этого бояться?
От: Pavel Dvorkin Россия  
Дата: 29.04.10 16:38
Оценка:
Здравствуйте, uzhas, Вы писали:

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


Для Windows есть HeapWalk.
With best regards
Pavel Dvorkin
Re[4]: Частое выделение памяти - стоит ли этого бояться?
От: Dzirt2005  
Дата: 29.04.10 16:38
Оценка:
Здравствуйте, _stun_, Вы писали:

__>Здравствуйте, Dzirt2005, Вы писали:



D>>Типа это не одно и то же с точки зрения поставленного вопроса?


__>Да типа нет.


Как раз практически одно и тоже — количество выделений/освобождений блоков памяти если и будет отличаться, то на неуловимую величину.
Re[3]: Частое выделение памяти - стоит ли этого бояться?
От: _stun_ Россия  
Дата: 29.04.10 16:41
Оценка:
Здравствуйте, uzhas, Вы писали:

U>вместо одной строчки во внутреннем скоупе вы написали 4 новых, причем увеличили скоуп жизни переменной

U>имхо, в данном случае пострадало качество кода и этого следует избегать

Про скоуп согласен, но это легко лечится, если приспичит.

Если в целом по качеству конкретного куска кода — то большой вопрос, на фига тут вообще vector

Ну а строчки мерить — занятие более бесполезное, чем борьба с фрагментацией.
Re[5]: Частое выделение памяти - стоит ли этого бояться?
От: _stun_ Россия  
Дата: 29.04.10 16:46
Оценка:
Здравствуйте, Dzirt2005, Вы писали:

D>Как раз практически одно и тоже — количество выделений/освобождений блоков памяти если и будет отличаться, то на неуловимую величину.


Сильно зависит от реализации и от того, что еще происходит в данном конкретном приложении. Очень не советую надеяться на удачу. Будет не лень — попозже расскажу страшную историю
Re[6]: Частое выделение памяти - стоит ли этого бояться?
От: Dzirt2005  
Дата: 29.04.10 16:53
Оценка:
Здравствуйте, _stun_, Вы писали:

__>Здравствуйте, Dzirt2005, Вы писали:


__>Сильно зависит от реализации и от того, что еще происходит в данном конкретном приложении. Очень не советую надеяться на удачу. Будет не лень — попозже расскажу страшную историю


А я не надеюсь... Я на исходный код vector'а посмотрел. В отличие от некоторых ленивых, которые строят предположения на кем-то рассказанных страшных историях Функция vector::clear() освобождает выделенную память и длина vector'а становится равной нулю. Поэтому если бы мне нужно было что-то типа такого кода я бы сразу избавился от claer(), а при постоянной длине и от resize(). Или вызывал бы resize только при необходимости увеличить буфер и увеличивал бы его с запасом. При этом количество выделений памяти было бы существенно меньше, а общее ее потребление осталось таким же как и было в первоначальном алгоритме. Если пренебречь фрагментацией кучи естественно
Re[7]: Частое выделение памяти - стоит ли этого бояться?
От: _stun_ Россия  
Дата: 29.04.10 17:14
Оценка:
Здравствуйте, Dzirt2005, Вы писали:

#include <vector>
#include <iostream>

int _tmain(int argc, _TCHAR* argv[])
{
    std::vector<char> vec;
    vec.reserve(100);
    std::cout << vec.capacity() << std::endl;
    vec.resize(10);
    std::cout << vec.capacity() << " " << (unsigned)&vec[0] << std::endl;
    vec.clear();
    std::cout << vec.capacity() << std::endl;
    vec.push_back(1);
    std::cout << vec.capacity() << " " << (unsigned)&vec[0] << std::endl;
    return 0;
}


И что у Вас выводится?
Re[7]: Частое выделение памяти - стоит ли этого бояться?
От: Ytz https://github.com/mtrempoltsev
Дата: 29.04.10 17:23
Оценка:
Здравствуйте, Dzirt2005, Вы писали:

D>А я не надеюсь... Я на исходный код vector'а посмотрел.


Какая реализация STL? По моему опыту как раз освобождения памяти не происходит, недаром даже идиома горячей усадки существует.
Re[5]: Частое выделение памяти - стоит ли этого бояться?
От: _stun_ Россия  
Дата: 29.04.10 17:36
Оценка:
Здравствуйте, Dzirt2005, Вы писали:

выделений/освобождений памяти удалось избежать.

D>Это ничего что освобождение и выделение памяти происходит именно в функциях clear() и resize() совершенно аналогично тому, как в исходом примере делалось то же самое происходило в конструкторе и деструкторе?


Вас уже выше спросили, в какой это реализации stl так злобно начихали на reserve() ?
Re[8]: Частое выделение памяти - стоит ли этого бояться?
От: Dzirt2005  
Дата: 29.04.10 17:57
Оценка:
Здравствуйте, 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]: Частое выделение памяти - стоит ли этого бояться?
От: Dzirt2005  
Дата: 29.04.10 17:59
Оценка:
Здравствуйте, _stun_, Вы писали:

__>Здравствуйте, Dzirt2005, Вы писали:


__>Вас уже выше спросили, в какой это реализации stl так злобно начихали на reserve() ?


Я там ответил...
Re: vector<>clear
От: Bell Россия  
Дата: 30.04.10 01:51
Оценка:
Здравствуйте, TailWind, Вы писали:

В связи с возникшими спорами про vector::clear: давным давно это обсуждали здесь
Автор:
Дата: 30.12.03
Любите книгу — источник знаний (с) М.Горький
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.