Re: sizeWithAttributes not actually leaking
Re: sizeWithAttributes not actually leaking
- Subject: Re: sizeWithAttributes not actually leaking
- From: Douglas Davidson <email@hidden>
- Date: Mon, 8 Oct 2001 10:26:45 -0700
On Saturday, October 6, 2001, at 12:27 PM, email@hidden
wrote:
For what it's worth, I just spent many hours fretting over the apparent
leak in NSString's -sizeWithAttributes.
It appears that what happens is that sizeWithAttributes is caching the
strings its getting the size of. If you call it repeatedly with
identical strings (but each still being uniquely created and
destroyed), there is no "leak." If you call it repeatedly with unique
strings, ObjectAlloc reveals that multiple
"NSConcreateAttributedString"s and an equal number of "NSRLEArray"s are
being created but not destroyed.
It goes on line this for somewhere between 100 and 300 invocations, so
you have 100-300 of these objects laying around, then they all get
flushed away. It took me a while to figure that out.
Just so. Bear in mind that most leak detectors report apparent
leaks--that is, memory for which they can find no current use. Just
because they do not find it doesn't mean it isn't there. The kit does a
great deal of caching in various places, and we also go to considerable
trouble to manage these caches and to detect leaks in our own code. In
general, there is usually little point in your hunting down arbitrary
apparent leaks unless they actually cause a secular increase in
application memory usage.
Douglas Davidson