Re: Leaking Memory
Re: Leaking Memory
- Subject: Re: Leaking Memory
- From: Robert Goldsmith <email@hidden>
- Date: Sat, 25 Jan 2003 02:07:39 +0000
>
Objects are "cleared" (deallocated) when their retain count drops to 0.
I am well aware of this so maybe my question should be 'when do retain
counts of autoreleased objects reach zero'. Now, as you have rightly
pointed out, in the absence of any other retains on the object, this is
when the autorelease pool is released.
>
>
"Generally", that's as much as we need to, or -- in the absence of any
>
other context -- can, say (bearing in mind basic rules of memory
>
management).
As a C programmer at heart, this is not good enough (just as the simple
memory -allocation- management was not good enough for you). I would
like to know exactly how long objects could stay around - give me error
bars, if you will.
You see, this is just as important as the retain/release cycle because,
although it will not cause a bus error, it can cripple a program - and
because it does not cause an error, many programmers may be blissfully
unaware they have 2000 temporary objects eating up memory and forcing
os x to use virtual memory pages.
>
The Application Kit creates a pool at the beginning of the event loop
>
and releases it at the end.
Ok, so in an event driven application, life is easier because you can
create thousands of objects and they will be cleared at the start of
the next event loop (how often is that, btw? any ideas?). How about
NON-event based applications?
For instance, if I was to have a method that used 5 temporary objects
(created with convenience messages to the class). This method is
messaged 1 million times. I was a good programmer and set up a pool
when I started. Are the temporary objects released like an int would be
in a c function? Or are they placed in the autorelease pool? I assume
the latter. So how often should a pool be cleared; i.e. how quickly
does the system get bogged down vs how long does it take to release the
pool and create another?
And can you release a pool and create a new one (without a pool below
to catch objects) without errors or leaks?
And, back to AppKit, if you create your own pool, is it this pool that
gets released at the end of each event loop? I assume not - but does
that mean that, if you are not careful, your pool ends up filled with
AppKit temporary items? So creating your own pools as you would in
non-event driven apps is a very bad idea for AppKit apps.
Questions, questions :)
As a C programmer, I do feel I need to know a little more about the way
things work so I can make judgments on how best to code a problem. It's
just the way I work. Of course, if this raises any questions for you as
well, then maybe your view on how memory management works is not so
complete after all. I never thought mine was.
I also suspect that, with so much talk of autorelease pools, many
newbies think that once they have that down pat, they don't need to
think about memory management further... a very incomplete and
inaccurate view indeed (if you want to be an efficient programmer, that
is).
Robert
---
GnuPG public key:
http://www.Far-Blue.co.uk/RSGoldsmith.asc
[demime 0.98b removed an attachment of type application/pgp-signature which had a name of PGP.sig]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.