Re: Converting from Carbon Event Manager to NSTimer
Re: Converting from Carbon Event Manager to NSTimer
- Subject: Re: Converting from Carbon Event Manager to NSTimer
- From: Uli Kusterer <email@hidden>
- Date: Fri, 26 Sep 2008 15:03:13 +0200
On 25.09.2008, at 01:18, Dan Birns wrote:
So what happened when I used [NSTimer
scheduledTimerWithTimeInterval... I was getting another timer. The
result was that my selector would get called maybe 10X more often
than intended. This didn't break anything, but impaired
performance. So now I simply add a call to [timer invalidate];
before adding a new timer. It's true that we're allocating a new
timer with every call, and I'd prefer not to do that, but this seems
to be working okay for now.
That can't really have happened unless you set the 'repeats' flag on
that timer, too.
Timers are a special case because they get retained both by the
current run loop when they're attached to it, and by you. Hence the
'invalidate' call, which removes it from the run loop again.
I must say, after 20 years of C malloc(), I find retain/release
mysterious. It's probably no better or worse than malloc/free, but
confusing to me. It seems to me that it has exactly the same
advantages/disadvantages, but it's just wildly different. Who does
the free()? Who does the retain/release? Pretty much the same
problem...
The main idea behind retain/release is to make shared ownership over a
given block of memory and passing memory between scopes easier. This
isn't supposed to be saving you from having to do memory management
manually. If you want less manual management, turn on the garbage
collector.
This might be a good opportunity for me to mention Episode 10 of Late
Night Cocoa:
<http://www.mac-developer-network.com/podcasts/latenightcocoa/episode10/index.html
>
where you can hear me going on and on about memory management and the
purpose and ideas behind retain/release.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden