Large Object Creation
-
I'm basically curious about the heap, and how the operating system manages this type of memory. I have a couple of applications, in which I have created and allocated alot of data which resides in a single C++ class instance, and I have not used any explicit heap memory allocation functions. This seems to work fine, and I'm not likely to have any security-related problems (these objects are NOT COM objects, nor, are they shared resources nor accessed externally from my local machine). The size of these objects are in the range of 100 KB to about 350 KB. I'm wondering if this is a good idea, to just let the memory manager allocate this data, or should I explicitly allocate a private heap? These objects are usually used just as single instances,...occasionally, it will be deleted and re-allocated, but typically they are just single use class objects. Of course, I could break up the objects into alot of smaller components, but, then again, is this necessarily a good idea? I'd appreciate any suggestions. Thanks.
-
I'm basically curious about the heap, and how the operating system manages this type of memory. I have a couple of applications, in which I have created and allocated alot of data which resides in a single C++ class instance, and I have not used any explicit heap memory allocation functions. This seems to work fine, and I'm not likely to have any security-related problems (these objects are NOT COM objects, nor, are they shared resources nor accessed externally from my local machine). The size of these objects are in the range of 100 KB to about 350 KB. I'm wondering if this is a good idea, to just let the memory manager allocate this data, or should I explicitly allocate a private heap? These objects are usually used just as single instances,...occasionally, it will be deleted and re-allocated, but typically they are just single use class objects. Of course, I could break up the objects into alot of smaller components, but, then again, is this necessarily a good idea? I'd appreciate any suggestions. Thanks.
How are you allocating the objects? Using
new?newallocates its memory from the heap. You're almost certainly better off leaving the memory allocation details to the system.Steve
-
I'm basically curious about the heap, and how the operating system manages this type of memory. I have a couple of applications, in which I have created and allocated alot of data which resides in a single C++ class instance, and I have not used any explicit heap memory allocation functions. This seems to work fine, and I'm not likely to have any security-related problems (these objects are NOT COM objects, nor, are they shared resources nor accessed externally from my local machine). The size of these objects are in the range of 100 KB to about 350 KB. I'm wondering if this is a good idea, to just let the memory manager allocate this data, or should I explicitly allocate a private heap? These objects are usually used just as single instances,...occasionally, it will be deleted and re-allocated, but typically they are just single use class objects. Of course, I could break up the objects into alot of smaller components, but, then again, is this necessarily a good idea? I'd appreciate any suggestions. Thanks.
Global variables kill optimization opportunities. Unless you understand memory well and will do all work from this class, you do not want to manage your own pool of memory like that. If you did chose to manage your own memory, then you may use C functions instead of new (especially if the data types are all primitive like double, long, int, etc.). This means that you have to handle construction, destruction properly yourself, but you can get speedups by bypassing unnecessary initializations.
-
I'm basically curious about the heap, and how the operating system manages this type of memory. I have a couple of applications, in which I have created and allocated alot of data which resides in a single C++ class instance, and I have not used any explicit heap memory allocation functions. This seems to work fine, and I'm not likely to have any security-related problems (these objects are NOT COM objects, nor, are they shared resources nor accessed externally from my local machine). The size of these objects are in the range of 100 KB to about 350 KB. I'm wondering if this is a good idea, to just let the memory manager allocate this data, or should I explicitly allocate a private heap? These objects are usually used just as single instances,...occasionally, it will be deleted and re-allocated, but typically they are just single use class objects. Of course, I could break up the objects into alot of smaller components, but, then again, is this necessarily a good idea? I'd appreciate any suggestions. Thanks.
It depends on your compilers runtime library but generally the operating system doesn't have a lot to do with the C++ heap. As a first approximation what happens for
newing objects is that the runtime allocates a big chunk of memory and then suballocates objects out of that block. When it runs out of that block it allocates another and starts allocating out of that. However the real world of C++ allocators and operating system heaps is rarely that simple anymore. For example Windows 2000 (I think, haven't got my reference books to check so I could well be wrong) introduced a small object heap that allocated chunks of memory for objects of different size ranges to avoid fragmentation of the heap. At least one C++ compiler I've used used a similar set of blocks for different sizes for the same reasons. Other optimisations I've seen include different heaps or blocks per thread. Most programmers don't want their threads blocking if a memory allocation is attempted and then there's the whole issue of using garbage collection for recovering memory for the heap rather than doing it when the program deletes an object. If you defer memory recovery to a garbage collector you end up avoiding one of the bottle necks in multithreaded code if the heap is shared between threads. So basically only worry about it if you find that you can't create the objects you need or if you've profiled your app and found that it's spending way too much time in the memory allocator. Cheers, Ash PS: There's no such thing as "class objects" in C++. Classes are just things the compiler sees, once the program is compiled classes don't really exist anymore, unlike Java or Smalltalk where everything's an object including classes. -
I'm basically curious about the heap, and how the operating system manages this type of memory. I have a couple of applications, in which I have created and allocated alot of data which resides in a single C++ class instance, and I have not used any explicit heap memory allocation functions. This seems to work fine, and I'm not likely to have any security-related problems (these objects are NOT COM objects, nor, are they shared resources nor accessed externally from my local machine). The size of these objects are in the range of 100 KB to about 350 KB. I'm wondering if this is a good idea, to just let the memory manager allocate this data, or should I explicitly allocate a private heap? These objects are usually used just as single instances,...occasionally, it will be deleted and re-allocated, but typically they are just single use class objects. Of course, I could break up the objects into alot of smaller components, but, then again, is this necessarily a good idea? I'd appreciate any suggestions. Thanks.
Yes, the objects are created with the new operator, that way I can just call delete on the object pointer. It's mostly for convenience. ...And, I only have one main thread in these applications,...the sequence of operations are not all that complicated. The end result is to write alot of the data to file. I had thought that for small objects, they would somehow live on the stack. (Shows you how ignorant I am of memory management.) The term "class objects" I just use to describe what is a contiguous block of data. You seemed to get the idea pretty clearly. Thanks for the information. I'll play around with it a little, just to get a better idea of how it works.