jls@hsv3.UUCP (James Seidman) (09/24/90)
The SDK doesn't describe very clearly (at least to me) how DLLs handle their local heap. It says at one point that the heap can grow if a LocalAlloc requires more memory than is currently available. Does it mean only up to the amount specified in HEAPSIZE? Does that mean that I can set HEAPSIZE to 64K and not necessary have that much memory munched if I don't allocate it? The reason I ask is that I have a DLL which can't determine until runtime how much space it needs. It could be anywhere from 5K to 62K, depending on the circumstances. I'd hate to reserve 62K where I only really needed 5K. (And please don't tell me to use GlobalAlloc(), either... I'm dereferencing pointers in tight loops and having them be far would cause performance impairments.) Thanks for any help! -- Jim Seidman (Drax), the accidental engineer. UUCP: ames!vsi1!headland!jls ARPA: jls%headland.UUCP@ames.nasa.arc.gov
roper@nwnexus.WA.COM (Michael Roper) (09/25/90)
James Seidman writes: > The SDK doesn't describe very clearly (at least to me) how DLLs handle > their local heap. It says at one point that the heap can grow if a > LocalAlloc requires more memory than is currently available. Does it > mean only up to the amount specified in HEAPSIZE? Does that mean that > I can set HEAPSIZE to 64K and not necessary have that much memory munched > if I don't allocate it? HEAPSIZE is the initial size of the heap. The heap can never be smaller than HEAPSIZE, but it can be bigger. > (And please don't tell me to use GlobalAlloc(), either... I'm > dereferencing pointers in tight loops and having them be far would cause > performance impairments.) If you have C 6.0, based pointers will solve your "tight loop" problem when using global memory. Michael Roper hDC Computer Corporation
matts@microsoft.UUCP (Matt SAETTLER) (10/01/90)
In article <4990@hsv3.UUCP> jls@headland.UUCP (James Seidman) writes: >In article <388@nwnexus.WA.COM> roper@nwnexus.UUCP (Michael Roper) writes: >>HEAPSIZE is the initial size of the heap. The heap can never be smaller >>than HEAPSIZE, but it can be bigger. > >That's what I thought, but when I do a LocalAlloc() which would require >extended the heap, it always fails. I'm using the standard LIBENTRY.OBJ >which comes in the sample code for the SDK, and compiling using the small >model. > When Windows goes to grow your LoacalHeap (which is a GlobalHeap element) it must have space after it, or be able to move it to where there is space. If you have declared the Data segment FIXED (in your .DEF file), then it cannot be moved. This is most likely your problem. Petzold's book explains memory management in pretty good detail. >>> (And please don't tell me to use GlobalAlloc(), either... I'm >>> dereferencing pointers in tight loops and having them be far would cause >>> performance impairments.) > >>If you have C 6.0, based pointers will solve your "tight loop" problem >>when using global memory. > >I've looked into this, and you're right, this is a very good suggestion. >BTW, I have heard that loading segment registers in protected mode takes >a VERY long time (36 cycles sticks in my mind). Is this true, and if so >does that have the type of performance implications I think it does for >medium model programs which do a lot of calling between segments? It does take much more time due to the protection checks. From the Int*l 80386 Progammer's Reference Manual: Instruction Clocks Description mov Sreg,r/m16 2/5, pm=18/19 Move r/m word to segment register pop Sreg 7,pm=21 Pop top of stack into segment register For medium model, grouping your functions so that the 'helper' functions are in a segment (and can be declared NEAR) means only a segment load hit when you call the interface points in that module. ---------------------------------------------------- I speak only for myself, or so I'm told to say...