Author: Scott Gasch
Date: 10:27:43 12/12/01
Go up one level in this thread
>that's what i thought too. i wasn't sure about where the hashtable was located >before, thanks for explaining. ... >i have also seen large speed differences between using global arrays for things >or using them as local arrays in the function that uses them, sometimes better >for the globals, sometimes better for the locals. i just would like to >understand what is better and why, so that i can "do the right thing" generally. >but it seems like no general rules exist :-( Well I can't help with a general rule for when to use each but I can better explain how this stuff works. The only general rule I know about memory is try to keep what you will need next in the cache. I designed several of my data structures so that when I touch one thing and know I will be touching another soon after, the first thing is just before the next in memory. Here's my long-winded description of how process memory works in win32, hope it's helpful to someone: When a process starts, two chunks of memory are allocated. One is the heap, the other is the stack. The initial size of these chunks is set by the linker and you can override it with your own values. Dynamically allocated memory comes from the heap (HeapAlloc, malloc, new, etc...). An algorithm is used to determine what chunk of heap memory to return for an allocation and when to combine two adjacent free chunks. The algorithm tries to keep a big chunk around so that a future large allocation will not exhaust the heap. A heap _can_ grow but not beyond the maximum size specified when it was created. If the heap is exhausted or becomes so fragmented that there is no contiguous chunk large enough to satisfy your request, the allocation request will fail. You can also create your own heaps (in addition to the process' default heap) and specify their (initial and max) sizes with HeapCreate. Local variables (except statics), function parameters, etc... are stored in the stack. The amount of memory in use on the stack grows and shrinks as functions get called and return. The last page of memory on the stack is a guard page which causes a kind of exception when it's accessed. The system catches this exception and uses it as a signal that the your process' stack needs to grow. This is a relatively slow process and there is no guarantee that the memory resources needed to grow will be available at that time. So it's especially important to set your initial stack allocation to a sufficient size. You can do this by watching the maximum stack size of your process while it runs in a debugger and then setting the initial stack allocation to that number in your project linker options. Global variables go in the actual program image. Where depends on the compiler of course but usually either in the .data section (if they are not initialized) or in the .bss (or .rdata) section (if they are initialized). VirtualAlloc doesn't use memory from any of these places -- it modifies the process' VAD tree and requests pages from the OS' virtual memory system. Scott
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.