i menas handles created by HeapCreate
Good question... I don't know if there's a limit on the number of heaps you can create, but the virtual address space of your process *will* limit it. I wouldn't create many heaps... the process default heap suffices for most misc. stuff. If I need a whole bunch of alloc/deallocs of temporary nature, I might create a secondary heap for this, and destroy it when done, to avoid fragmenting the main heap too much.
I guess that creating small non-growable heaps aren't too bad if you have some reason for it, though?
I guess that creating small non-growable heaps aren't too bad if you have some reason for it, though?
well i creale realy a lot Heaps. Even when i nead 256 for file name i create heap for it.
That's a bad idea - you shouldn't create a heap for each allocation you do. For simple stuff like this, just use HeapAlloc with GetProcessHeap... you really should only do HeapCreate when you have 'special needs'.
You can also use HeapCompact to reduce heap fragmentation, or, if you are under WinXP, you can use LFH (Low Fragmentation Heap).
If you do a lot of allocation and deallocation from a heap, create only one heap, and then use HeapAlloc and HeapFree with HEAP_NO_SERIALIZE flag. This speeds up allocation and deallocation
If you do a lot of allocation and deallocation from a heap, create only one heap, and then use HeapAlloc and HeapFree with HEAP_NO_SERIALIZE flag. This speeds up allocation and deallocation
I played around a bit, and I failed to see much improvement from creating my own heap and specifying HEAP_NO_SERIALIZE - this was on win2k, perhaps it matters more on win9x. Also, remember that HEAP_NO_SERIALIZE makes your code non-threadsafe.
That's a bad idea - you shouldn't create a heap for each allocation you do. For simple stuff like this, just use HeapAlloc with GetProcessHeap... you really should only do HeapCreate when you have 'special needs'.
why bad idea. I do not do it when the speed is critical.Also i destroy heap after few lines of code so there is no a lot of heaps at the same times.
I dont like to use part of memory from Heap, i like when there is no leftovers or unused space so i alocate EXACTLY as much memory as it is neaded for particular task.
And what Special Needs are you talking about ??
I played around a bit, and I failed to see much improvement from creating my own heap and specifying HEAP_NO_SERIALIZE - this was on
win2k, perhaps it matters more on win9x. Also, remember that HEAP_NO_SERIALIZE makes your code non-threadsafe.
I know. I'm only quoting microsoft
There is a small performance cost to serialization, but it must be used whenever multiple threads allocate and free memory from the same heap.
You can use it only if you have one thread that access it.
This value should not be specified when accessing the process heap. The system may create additional threads within the application's process, such as a CTRL+C handler, that simultaneously access the process heap.
why bad idea. I do not do it when the speed is critical.Also i destroy heap after few lines of code so there is no a lot of heaps at the same times.
I dont like to use part of memory from Heap, i like when there is no leftovers or unused space so i alocate EXACTLY as much memory as it is neaded for particular task.
Creating extra heaps means (temporarily) using more committed memory than if you only used one heap, it means using more virtual address space, and there's more code overhead. Thus, creating an extra heap doesn't mean allocating EXACTLY as much memory as is needed - it's more. There isn't really any reason for doing this, either... it's all extra overhead and memory usage for nothing - when you HeapFree, the memory is again available to your process, so this isn't a reason for lots of HeapCreate+HeapDestroy either.
And what Special Needs are you talking about ??
Suppose a part of your program needs to do a lot of memory allocation, and perhaps a lot of mixed alloc/free. At the same time, either because you're multithreaded or because you have main code the calls into this specific portion of your program, you need to do other memory allocations. When the sub-part of your program is done, all memory used by it is heapfree'd - this would leave you with a fragmented heap, and thus it might be a good idea to create a second temporary heap for the sub-part of your program, and/or research alternative allocation strategies.
You shouldn't generally used HeapAlloc+HeapDestroy to avoid doing proper memory tracking and HeapFree. However, in some situations it might be okay to do this - like the case where you need a *lot* of small memallocs with a limited lifetime, it could be advantagous to get rid of the whole lot with a HeapDestroy instead of a lot of calls to HeapFree and a fragmented heap.
But using HeapCreate for every HeapAlloc is plain stupid, it serves no purpose - it's sorta like insisting on CreateFile+FileRead+CloseFile for every buffer read, instead of keeping the file open for the duration of your file operations.
Speaking of heaps, I have one question about HeapRealloc()
Consider memory blocks that need to be resized (growed) from time to time, what would be faster solution
1. To use HeapRealloc for resizing
2. To manually allocate new bigger memory block, then to use some optimized proc (like MemCopy from asm32lib) to copy current memory block to new bigger one, and then to deallocate old smaller block.
Consider memory blocks that need to be resized (growed) from time to time, what would be faster solution
1. To use HeapRealloc for resizing
2. To manually allocate new bigger memory block, then to use some optimized proc (like MemCopy from asm32lib) to copy current memory block to new bigger one, and then to deallocate old smaller block.
Depends on the usage pattern. If you don't have allocations after the one you need to resize, it can just be grown, and that will be faster than alloc+copy. If it can't be grown and you're dealing with a relatively large block, doing alloc+copy+free yourself will probably be faster.
But if you're in a case where this speed is important to you, I'd say you're probably best off building your own allocator ontop of HeapAlloc or VirtualAlloc...
But if you're in a case where this speed is important to you, I'd say you're probably best off building your own allocator ontop of HeapAlloc or VirtualAlloc...
Creating extra heaps means (temporarily) using more committed memory than if you only used one heap, it means using more virtual address space, and there's more code overhead. Thus, creating an extra heap doesn't mean allocating EXACTLY as much memory as is needed - it's more. There isn't really any reason for doing this, either... it's all extra overhead and memory usage for nothing - when you HeapFree, the memory is again available to your process, so this isn't a reason for lots of HeapCreate+HeapDestroy either.
But using HeapCreate for every HeapAlloc is plain stupid, it serves no purpose - it's sorta like insisting on CreateFile+FileRead+CloseFile for every buffer read, instead of keeping the file open for the duration of your file operations.
From programer point of view i alocate exactly what is needed i dont give a s***t what OS is doing with this.
About this second part i have made such a macros Just like for Heap but for MemoryMapping :tongue: , maby it's stupid becouse of disadventages you have spoke about but thanks to this i avoid mess in source, i allways have closed handles when i dont need them.
Usually i cant predict how many memory i will need so using only one heap i will have to check if my memory space is big enought every time im going to write there something ( more typing :P).
From programer point of view i alocate exactly what is needed i dont give a s***t what OS is doing with this.
If you do a HeapCreate for every memory allocation, you are NOT allocating exactly what you need - you are allocating a lot more. This is plain silly, and there is no excuse for doing this.
maby it's stupid becouse of disadventages you have spoke about but thanks to this i avoid mess in source, i allways have closed handles when i dont need them.
So rather than doing proper code, you choose an easy way and create sloppy code? Yay.
In case you don't understand the concept, a heap is much like a stack, it's a pre-allocated piece of memory, from which you can dynamically allocate and deallocate memory easily.
Using more than one heap in a program is as useful as using more than one stack. You rarely need to do this.
And what f0dder is trying to explain, is that creating a heap will allocate a pool of memory to your application, which will be used for subsequent HeapAlloc()-calls on that specific heap. If you use n heaps, you have n such pools, and occupy n times the amount of memory for such a pool. So in short, don't do it, it makes no sense.
Using more than one heap in a program is as useful as using more than one stack. You rarely need to do this.
And what f0dder is trying to explain, is that creating a heap will allocate a pool of memory to your application, which will be used for subsequent HeapAlloc()-calls on that specific heap. If you use n heaps, you have n such pools, and occupy n times the amount of memory for such a pool. So in short, don't do it, it makes no sense.
:grin: HeapCreate rounds its size up to the next page boundary. Lol it looks like i realy make big crap :tongue:.i will have to change my bad habits :sweat:
Btw how big is process heap ??
I think should be some like.. the total virtual memory, and to this value you restate :
the data, data? (bss..), code(text), and at runtime the stack, that go up to down..., and maybe a little about the formnat that the executable file is loaded at memory, also see that virtual memory , mean that not all this range of memory is mapped actually, only the necesary is mapped (or projected.. dunno how you say it), requesting size for the heap, mean that you are saying to the OS that you whant more of this virtuaol space to be projected really to the main memory (also later when you dont use posibily to the disck...)
Have a nice day or night.
the data, data? (bss..), code(text), and at runtime the stack, that go up to down..., and maybe a little about the formnat that the executable file is loaded at memory, also see that virtual memory , mean that not all this range of memory is mapped actually, only the necesary is mapped (or projected.. dunno how you say it), requesting size for the heap, mean that you are saying to the OS that you whant more of this virtuaol space to be projected really to the main memory (also later when you dont use posibily to the disck...)
Have a nice day or night.