Tiny allocations are wasteful on most operating systems. If I were to
hazard a guess I'd say that the rule is something like 'round up to even
word boundaries and add 8 for block info'. I'd be curious if the
MemPrtNew(1) is your app's first dynamic allocation. There might be
extra overhead for the first allocation. 3 and 6 seem odd, unless the
allocations are sequential and the heap is a dword aligned linked list.
I've never bothered to trace the memory management to see if it actually
maps to the AMX memory management services (with extra stuff on top).
AMX actually has two memory managers. A thread safe (I guess 'task
safe' in AMX terms) heap manager (which can handle multiple heaps) and a
'buffer' manager. Instead of allocating and freeing small transfer
buffers, string buffers, or whatever over and over (and potentially
fragmenting your heap) you make one heap allocation and then use the
buffer manager to divvy up that allocation into fixed size reusable
buffers. It's kind of neat but the PalmOS Heap 0 has traditionally been
so small I'm not sure how useful it would be if it, or something like
it, were exposed.
Back under Windows 3.1 Borland and Microsoft compilers used to allocate
memory from the OS in 8 or 16K chunks and then divvy it up in the RTL to
avoid the high overhead on each system allocation.
Best Regards,
-jjf
-----Original Message-----
From: Jeff Ishaq [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 24, 2000 2:57 PM
To: Palm Developer Forum
Subject: RE: Why does MemPtrNew(1) eat up 16 bytes?
Well my original test code looked like this:
CharPtr p1;
p1 = (CharPtr) MemPtrNew(1);
p1 = (CharPtr) MemPtrNew(2); // yes I know this leaks
p1 = (CharPtr) MemPtrNew(3);
etc etc...
It seems like for storing a bunch of short strings (1-10 characters in
length) in dynamic memory, it's a lot more efficient to MemPtrNew(100),
and
then just move the strings around inside of that block, growing it as
necessary. Wasting 8-15 bytes in padding for 10-20 strings gets pretty
costly after a while.
-Jeff
> -----Original Message-----
> From: Fitzpatrick, Joe [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 24, 2000 5:55 PM
> To: Palm Developer Forum
> Subject: RE: Why does MemPtrNew(1) eat up 16 bytes?
>
>
> Are you doing this in a loop (for (x = 1 ; ...)) or one run at a time?
>
> -jjf
>
> -----Original Message-----
> From: Jeff Ishaq [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 24, 2000 1:26 PM
> To: Palm Developer Forum
> Subject: Why does MemPtrNew(1) eat up 16 bytes?
>
>
> Well this is interesting. Check out this data:
>
> The environment:
> CW6 on POSEr 3.0a3. Identical results were obtained using
> the 3.0 debug
> and
> 3.0 release ROM images from Palm's webpage.
>
> The test code:
>
> MemHeapFreeBytes(0, &freeInitial, &max);
> CharPtr pTest = (CharPtr) MemPtrNew(x);
> MemHeapFreeBytes(0, &freeFinal, &max);
> delta = freeInitial - freeFinal;
>
> x <- next value // pseudocode
> repeat test code // pseudocode
>
> The results:
> x delta excess padding
> 1 16 15
> 2 10 8
> 3 14 11
> 4 12 8
> 5 14 9
> 6 18 12
> 7 16 9
> 8 16 8
> 9 18 9
> 10 18 8
> 20 28 8
> 30 38 8
> 40 48 8
>
>
> Can someone explain what's going on here? Am I doing something silly?
> I
> see that each chunk has the overhead of its own
> MemChunkHeaderType (I'm
> guessing this takes up 8 bytes, or two DWords). I also assume DWord
> alignment to be considered. But I can't put a finger on
> exactly what's
> going on, especially with x=1, 3, and 6.
>
> This is so much fun!
> -Jeff
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
> please see http://www.palm.com/devzone/mailinglists.html
>
> --
> For information on using the Palm Developer Forums, or to
> unsubscribe, please see http://www.palm.com/devzone/mailinglists.html
>
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palm.com/devzone/mailinglists.html
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
