[EMAIL PROTECTED] wrote:
>>Are you saying that I should check for memory required to load a form,
>>for example, before loading the form?
>
>Looking through the PIM applications source code, you won't see any runtime
>checks for this. Instead, during development time, we look at the heap
>after the form is loaded to make sure there's a good amount of room left.
Yeah, I did notice this. But I'm not inclined to trust myself too much in
interpreting the meaning of the code. That's what prompted me to ask.
>>1) Ensuring that my code is always leaving sufficient headroom for "non
>>optional requests", that unspecific number you refer to
>Use this method.
Sorry Roger, you mean the "check after loading the form" method?
>If you need a bit of memory for a short bit of time, put it on the stack
>(local variable). The benefits are the memory is cheap to allocate and
>destroy. Don't do this for memory that 1) stays around a long time, 2) is
>large, or 3) will be resized. Note that large varies. You can use a lot
>more space in a function that never calls anything than one that allways
>exists like PilotMain, because the later choice affects all other calls
>from PilotMain.
>If you need memory for the entire app and you need to read and write from a
>variety of places, use your app's global memory. The benefits are the
>memory is cheap to allocate and destroy. The drawbacks are 1) this doesn't
>work other other launch commands and 2) it reduces the memory available for
>the rest of the program. Obviously the amount of memory must be known at
>compile time.
>
>You'll need to use dynamically allocated memory for all the other requests.
>The decision for pointer based chunks versus handle based isn't too hard to
>make. Use handles if the memory is going to be resized. Use handles if
>the memory is going to be allocated or destroyed at unpredictable times.
>Use pointers for memory that is going to be allocated in an orderly manner,
>like a function that allocates a bunch in a row and frees all before
>exiting, or a bunch of allocates at the beginning of an app. The idea here
>is that the pointer based memory should be allocated and freed in order.
>Doing otherwise leaves holes which slows down the memory manager from
>finding unused memory. Handles based memory should be left unlocked so
>that it can compact and rearrange memory. Pointer and handle based memory
>come from the same dynamic heap. Pointer based memory descends from the
>top and handle based goes the other direction. They meet when the heap
>fills up. Pointer based memory is a tiny bit faster than handle based.
>
>
>If you have data that needs to be stored or is read only, keep it in the
>storage heap.
I have framed the section above and hung it on the wall next to the
computer. ;-) That's the most lucid explanation I've ever read. While
I'm certain there are exceptions (there are always exceptions), you've
given me a solid starting point.
>Generally people who have lot's of memory questions haven't used the
>console commands to inspect the memory heaps.
Well actually, <sheepish grin> I only recently (Sunday) found any
documentation on the console. Here I was looking in the Debugger manual
(since it's called the Debugging Console...)and the other API volumes
instead of looking in the somewhat less than intuitive Cookbook (!).
I have used the console commands but without understanding what I was
looking at. Having read the console documentation, things are somewhat
more clear.
>This is the Address Book after starting. Notice how little memory
>the app takes up.
>- -----------------
>Heap Summary:
> flags: 4000
> size: 016A5E
> numHandles: #200
> Free Chunks: #2 (01114E bytes)
> Movable Chunks: #4 (0008AE bytes)
> Non-Movable Chunks: #38 (004D2E bytes)
> Owner 0: 01641E bytes
> Owner 2: 00030C bytes
Roger, when I issue the command hd 0 I don't see the "Owner" tags you show
here. I assume that one of these represents the Address application (Owner
2?).
Also, I see three owners, 0, 15 and 1. I'm assuming that 0 and 15 are
system use and 1 represents my application. Here's the summary:
Heap Summary:
flags: 8000
size: 016B80
numHandles: #40
Free Chunks: #3 (011834 bytes)
Movable Chunks: #43 (00529C bytes)
Non-Movable Chunks: #0 (000000 bytes)
But perhaps this should be in the console thread...
Again, thank you for taking the time to explain this.
Cheers,
--
Andrew Ball
[EMAIL PROTECTED]
