分配内存显示任务管理器中内存使用量翻了一番 [英] allocating ram shows double the ram usage in task manager

查看:138
本文介绍了分配内存显示任务管理器中内存使用量翻了一番的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

进行一些性能分析(内存和速度),事实是win7似乎分配的内存正好是我要求的RAM的两倍...请注意,这是我第一次在win7上进行这种有效的性能分析,所以我真的不知道会发生什么.

Doing some profiling (mem & speed) I've been stomped by the fact that win7 seems to be allocating exactly double the RAM I ask for... Note this is the first time I do such active profiling on win7, so I don't really know what to expect.

我正在使用win7(64位)下的MSVC速成版在一个循环中分配精确数量的RAM.该应用程序已编译并以32位运行.

I'm allocating precise amounts of RAM in a loop using an express edition of MSVC under win7 (64-bit). The application is compiled and runs in 32 bit.

我分配了24 MB的内存,任务管理器显示我的应用使用48MB(在所有内存列下,包括已提交的内存,因为我实际上是在新区域中进行内存复制).当我再获得24个(现在应该是48MB)时,我的应用跳到96个,依此类推.

I allocate 24 MB of ram and the task manager shows my app as using 48MB (under all memory columns, including committed, since I'm actually memcopy'ing within the new regions). When I get 24 more (should now be 48MB), my app jumps to 96, etc.

这些被分配为1,000,000个24字节结构.

These are allocated as 1,000,000 24 byte structs.

我已经在网上搜索了,但没有发现与我的观察结果完全匹配的东西.

I've searched on the net but have found nothing to match my observations exactly.

有人知道吗?

如果这仅仅是操作系统的ery俩(或功能不足?),是否有任何工具可以使我真正了解进程的内存消耗? (当应用程序以;-开头时,很难发现泄漏)

If this is just OS trickery (or incompetence?), is there any tool which can give me the real memory consumption of a process? (its hard to find leaks, when the app gushes to begin with ;-)

[-----------已编辑,其他信息-----------]

[----------- edited, additional info -----------]

请注意(通过控制台标题栏中的路径)我正在发布模式下构建(使用MSVC 2010的所有默认空"项目设置),因此没有分配额外的调试"内存(可以将其设置为在某些项目上相当广泛).

Note (by the path in the console title bar) that I am building in Release mode (using all default "empty" project settings of MSVC 2010), so there is no additional "debugging" memory being allocated (which can be quite extensive on some projects).

这是一个简短的完整的C应用程序,用于说明行为:

here is a short, complete C app which illustrates the behavior:

#include <stdio.h>
#include <assert.h>
#include <conio.h>
#include <stdlib.h>
typedef unsigned int u32;
typedef struct myStruct MYS;
struct myStruct {
    u32 type;
    union {
        u32 value; 
        char * str;
        void * data;
        MYS ** block;
        MYS * plug;
    };
    u32 state, msg,  count, index;
};
int main(int argc, char *argv[]){
    int i, j;
    MYS *ref;
    printf ("size of myStruct: %d\n\n", sizeof(MYS));
    for(i=0; i < 10; i ++){
        printf("allocating started...\n");
        for (j = 0; j < 1000000 ; j ++){
            ref = (MYS *) malloc(sizeof(MYS));
            assert(ref);
            memset(ref, 0, sizeof(MYS));
        }
        printf("   Done... Press 'enter' for Next Batch\n");
        _getch();
    }
    _getch();
    return 0;
}

和一幅图像,显示一个循环后我机器上的内存.每运行一次,它就会增加〜48MB而不是24MB!

and an image which shows the memory on my machine after one loop. Every other run, it adds ~48MB instead of 24MB!

推荐答案

这可能是由于填充,内部整理结构和内存对齐限制的组合.

This is probably due to a combination of padding, internal housekeeping structures, and memory alignment restrictions.

当您调用malloc(size)时,实际上并没有获得size个字节的缓冲区.您获得的缓冲区至少为 size个字节.这是因为出于效率方面的考虑,您的OS倾向于仅以几种不同的大小来处理内存缓冲区,并且不会定制缓冲区来节省空间.例如,如果在Mac OS上要求24字节,则将得到32字节的缓冲区(浪费25%).

When you invoke malloc(size), you don't actually get a buffer of size bytes. You get a buffer that is at least of size bytes. This is because, for efficiency reasons, your OS prefers to hand memory buffers in just a couple of different sizes and will not tailor buffers to save space. For instance, inf you ask for 24 bytes on Mac OS, you'll get a buffer of 32 bytes (a waste of 25%).

增加了分配开销,您的操作系统将使用这些结构来管理malloc缓冲区(可能每个分配占用几个额外的字节),并且填充可能会增加对象的大小(为您的倍数)编译器的首选对齐方式),您会发现将数百万个小对象分配到各个缓冲区中非常昂贵.

Add to that allocation overhead the structures your OS uses to manage malloced buffers (probably accounting for a few extra bytes per allocation), and the fact that padding may increase the size of your object (to a multiple of your compiler's preferred alignment), and you'll see that allocating millions of small objects into individual buffers is very expensive.

长话短说:仅分配sizeof (YourType) * 1000000的一个大缓冲区,您应该不会看到任何明显的开销.分配一百万个sizeof (YourType)对象,您最终将浪费大量空间.

Long story short: allocate just one big buffer of sizeof (YourType) * 1000000 and you shouldn't see any noticeable overhead. Allocate a million of sizeof (YourType) objects, and you'll end up wasting a lot of space.

这篇关于分配内存显示任务管理器中内存使用量翻了一番的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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