STL和池内存 [英] STL and pooling memory

查看:80
本文介绍了STL和池内存的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,

有人知道STLPort或SGI STL标准分配器是否有内存

汇集列表,地图和设置?

我还看了一下BOOST pool_alloc(用作列表的汇集

分配器),但查看代码似乎没有任何东西

发布(给全局::免费)曾经分配的内存。


我能理解如果我有另一个列表可以重复使用这样的内存
在程序后面的
相同的对象类型,但在我看来,

这样的pool_alloc无论如何应该释放块恰好是完全免费的
(* )否则程序将总是看起来具有

峰值内存分配给操作系统。像漏水一样!难道不是吗?
真的可以释放积木,或者是我的俯视?

(*)你完成后可能有很多完全免费的积木

使用一堆池化列表,如果实现的话,那么我认为每个新的alloc调用总是返回第一个空闲槽:

它是一个autodefragmenting算法

Hi all,
Does anybody know if STLPort or SGI STL standard allocators do memory
pooling for the list, map and set?
Also I have had a look at the BOOST pool_alloc (to be used as a pooling
allocator for lists), but looking into the code it doesn''t seem to ever
release (to the global ::free) the memory that was once allocated.

I can understand that such memory can be re-used if I have another list
of the same object types later in the program, but it seems to me that
such pool_alloc should anyway release blocks which happen to be
completely free (*) otherwise the program will always appear to have the
peak memory allocation to the operating system. Like leaking! Doesn''t it
really ever free the blocks, or it''s my overlook?
(*) there are likely to be many totally free blocks after you finish
working with a bunch of pooled lists, if the implementation is what it
seemed to me: every new alloc call always returns the first free slot:
it''s an autodefragmenting algorithm

推荐答案

aaaaa写道:
aaaaa wrote:
大家好,<是否有人知道STLPort或SGI STL标准分配器是否为列表,映射和设置做内存汇集?


我记得SGI有一个网页,他们解释说他们在他们的分配器中做了一些

汇集。我不知道STLPort。

我还看了一下BOOST pool_alloc(用作列表的池化分配器),但查看代码它没有''似乎永远不会释放(对全局::免费)曾经分配过的内存。

我可以理解,如果我有另一个列表,可以重新使用这样的内存。 />在程序后面的相同对象类型,但在我看来,这样的pool_alloc应该发布碰巧完全免费的块(*)否则程序总是会出现
峰值内存分配给操作系统。像漏水一样!难道它不是真的可以释放积木,或者它是我的俯视?
Hi all,
Does anybody know if STLPort or SGI STL standard allocators do memory
pooling for the list, map and set?
I recall that SGI had a web page where they explained that they do some
pooling in their allocators. I do not know about STLPort.
Also I have had a look at the BOOST pool_alloc (to be used as a pooling
allocator for lists), but looking into the code it doesn''t seem to ever
release (to the global ::free) the memory that was once allocated.

I can understand that such memory can be re-used if I have another list
of the same object types later in the program, but it seems to me that
such pool_alloc should anyway release blocks which happen to be
completely free (*) otherwise the program will always appear to have the
peak memory allocation to the operating system. Like leaking! Doesn''t it
really ever free the blocks, or it''s my overlook?




你确定打电话给free()会将内存释放到

操作系统。据我所知,该标准的语言,

仅为free()提供的保证是一个解除分配的区域将可用于malloc()调用的
同样的计划。 (实际上,可以读取C ++继承free()的C

标准,以便free()的

后置条件实际上是内存可用对于

后续调用malloc(),在这种情况下,不得将内存返回给操作系统
。)


在我的系统上,我只是使用以下代码来检查free的行为。

我符合我概述的标准的解释:没有

点,内存是返回操作系统。

#include< list>

#include< iostream>

#include< string>


typedef char page [1024];

typedef page * page_ptr;


int main(void){

std :: list< page_ptr> ptr_list;

std :: cout<< 分配300 MB的内存。\ n;;

for(unsigned int i = 0; i< 300000; ++ i){

ptr_list.push_back (reinterpret_cast< page_ptr>(malloc(sizeof(page

))));

}


{

std :: cout<< 已完成分配,按Enter键进行重新分配。;

std :: string line;

std :: getline(std :: cin,line);

std :: cout<< " \ n";

}


while(!ptr_list.empty()){

free(ptr_list。 back());

ptr_list.pop_back();

}


{

std :: cout<< deallocation done,hit。;

std :: string line;

std :: getline(std :: cin,line);

std :: cout<< " \ n";

}


std :: cout<< 再次分配300 MB内存。\ n;

for(unsigned int i = 0; i< 300000; ++ i){

ptr_list。 push_back(reinterpret_cast< page_ptr>(malloc(sizeof(page

))));

}


{

std :: cout<< 已完成分配,按Enter键进行重新分配。;

std :: string line;

std :: getline(std :: cin,line);

std :: cout<< " \ n";

}


while(!ptr_list.empty()){

free(ptr_list。 back());

ptr_list.pop_back();

}


{

std :: cout<< 点击进入退出。;

std :: string line;

std :: getline(std :: cin,line);

std :: cout<< " \ n";

}


}

如果你真的需要将内存返回给操作系统,那么你将有

来编写你自己的分配器并使用系统调用,这是系统特定的

并被认为是该组中的主题。

Best


Kai-Uwe Bux



Are you sure that a call to free() will release the memory to your
operating system. As far as I understand the language of the standard, the
only guarantee given for free() is that a deallocated region will be
available to malloc() calls from the same program. (Actually, the C
standard, from which C++ inherits free(), can be read so that the
postcondition of free() actually is that the memory will be available for
subsequent calls to malloc() in which case the memory must not be returned
to the operating system.)

On my system I just used the following code to check the behavior of free.
I conforms the the interpretation of the standard that I outlined: at no
point, memory is returned to the operating system.
#include <list>
#include <iostream>
#include <string>

typedef char page [1024];
typedef page* page_ptr;

int main ( void ) {
std::list< page_ptr > ptr_list;
std::cout << "allocating 300 MB of memory.\n";
for ( unsigned int i = 0; i < 300000; ++i ) {
ptr_list.push_back( reinterpret_cast< page_ptr >( malloc( sizeof( page
) ) ) );
}

{
std:: cout << "allocation done, hit enter for deallocation.";
std::string line;
std::getline( std::cin, line );
std::cout << "\n";
}

while( ! ptr_list.empty() ) {
free( ptr_list.back() );
ptr_list.pop_back();
}

{
std:: cout << "deallocation done, hit.";
std::string line;
std::getline( std::cin, line );
std::cout << "\n";
}

std::cout << "allocating 300 MB of memory again.\n";
for ( unsigned int i = 0; i < 300000; ++i ) {
ptr_list.push_back( reinterpret_cast< page_ptr >( malloc( sizeof( page
) ) ) );
}

{
std:: cout << "allocation done, hit enter for deallocation.";
std::string line;
std::getline( std::cin, line );
std::cout << "\n";
}

while( ! ptr_list.empty() ) {
free( ptr_list.back() );
ptr_list.pop_back();
}

{
std:: cout << "hit enter to quit.";
std::string line;
std::getline( std::cin, line );
std::cout << "\n";
}

}
If you really need to return memory to the operating system, you will have
to write your own allocator and use system calls, which are system specific
and considered off topic in this group.
Best

Kai-Uwe Bux


aaaaa写道:

我能理解这样的如果我在程序后面有另一个相同对象类型的列表,可以重复使用内存,但在我看来,这样的pool_alloc无论如何都应该发布完全相同的块。 free(*)否则程序将始终显示为操作系统分配峰值内存。像漏水一样!难道它不是真的释放了块,或者它是我的俯视?

I can understand that such memory can be re-used if I have another list
of the same object types later in the program, but it seems to me that
such pool_alloc should anyway release blocks which happen to be
completely free (*) otherwise the program will always appear to have the
peak memory allocation to the operating system. Like leaking! Doesn''t it
really ever free the blocks, or it''s my overlook?




你可能想看看我们的CoreX包,有一个工具包,用于构建自定义分配器的
。你可以编写分配器来隔离他们的内存,这样它就不能用于应用程序的其余部分,

你可以编写释放内存的分配器。


-


Pete Becker

Dinkumware,Ltd。( http://www.dinkumware.com


On Thu,16 2004年9月21:16:10 -0500,aaaaa< aa *** @ aaa.com>写道:
On Thu, 16 Sep 2004 21:16:10 -0500, aaaaa <aa***@aaa.com> wrote:
大家好,
有人知道STLPort或SGI STL标准分配器是否为列表,映射和设置做内存汇集?


是的,他们这样做,并且可以使用#defines进行配置(但默认情况下会打开

IIRC)。阅读文档。

此外,我还看了一下BOOST pool_alloc(用作列表的池化分配器),但查看代码似乎没有永远释放(对全局::免费)曾经分配过的内存。


这听起来不错。请注意,对于std :: list,你应该使用fast_pool_allocator

,因为我认为列表使用的单元分配比如

更快。


您可以使用底层单例

池分配器手动释放空闲空间。类似于:


singleton_pool< fast_pool_allocator_tag,

size_of_list_node> :: release_memory();


这个故障是可移植地计算出列表节点的大小,而且我不知道有没有办法做到这一点。您可能会这样猜:


模板< class T>

struct list_node_sizer

{

test * pre;

test * post;

T t;

};


singleton_pool< fast_pool_allocator_tag,

sizeof(list_node_sizer< MyType>)> :: release_memory();


我能理解这样的内存可以重复使用如果我在程序的后面有另一个相同对象类型的列表,但在我看来,这样的pool_alloc无论如何应该释放碰巧完全免费的块(*)否则程序将始终显示为操作系统的峰值内存分配。像漏水一样!难道它不是真的释放了块,或者它是我的俯视?
Hi all,
Does anybody know if STLPort or SGI STL standard allocators do memory
pooling for the list, map and set?
Yes, they do, and it''s configurable with #defines (but on by default
IIRC). Read the docs.
Also I have had a look at the BOOST pool_alloc (to be used as a pooling
allocator for lists), but looking into the code it doesn''t seem to ever
release (to the global ::free) the memory that was once allocated.
That sounds correct. Note that you should be using fast_pool_allocator
for std::list, since I think it''s faster for unit allocations such as
used by list.

You can manually free slack space by using the underlying singleton
pool allocator. Something like:

singleton_pool<fast_pool_allocator_tag,
size_of_list_node>::release_memory();

This hitch is working out the size of a list node portably, and I''m
not sure there''s a way of doing it. You could guess like this:

template <class T>
struct list_node_sizer
{
test* pre;
test* post;
T t;
};

singleton_pool<fast_pool_allocator_tag,
sizeof(list_node_sizer<MyType>)>::release_memory() ;

I can understand that such memory can be re-used if I have another list
of the same object types later in the program, but it seems to me that
such pool_alloc should anyway release blocks which happen to be
completely free (*) otherwise the program will always appear to have the
peak memory allocation to the operating system. Like leaking! Doesn''t it
really ever free the blocks, or it''s my overlook?




如果你想控制内存使用量,它可能是最好使用

非单例分配器。提升没有一个,但我肯定可以根据他们所拥有的东西来写一个最难的东西 - 最难的是处理

反弹副本分配器。


Tom



If you want to control memory usage, it might be better to use a
non-singleton allocator. boost don''t have one, but I''m sure one can be
written based on what they''ve got - the hardest thing is handling
rebound copies of the allocator.

Tom


这篇关于STL和池内存的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆