Re: correctly Controlling Garbage Collection
Re: correctly Controlling Garbage Collection
- Subject: Re: correctly Controlling Garbage Collection
- From: Quincey Morris <email@hidden>
- Date: Sat, 17 Oct 2009 20:55:07 -0700
On Oct 17, 2009, at 18:48, Rob Keniger wrote:
What happens if you explicitly disable Garbage Collection when the
user starts drawing and enable it when the user finishes?
That might be a practical answer, but I think maybe a key point got
skipped over earlier in the thread. If the collector causes a
*noticeable* pause in the mouse tracking, then presumably it has a
fair amount of work to do. (Lots of unreferenced blocks to reclaim,
for example, or lots of memory to scan).
Unless someone wants to claim that the creation and freeing of NSEvent
objects (and such like) by the framework produces such a volume of
work for the collector (which I doubt, though have to evidence for),
the possible implication is that the application code for handling the
events is generating lots of objects with short lifetimes. In that
case, the correct solution is to rearchitect the event handling to
avoid creating so many objects.
Of course, other possibilities include: (a) a bug in the frameworks,
and (b) an unfortunate edge scenario where neither frameworks nor
application is doing anything wrong, but the collector happens to
perform poorly.
Whatever the cause, surely the *only* reasonable way to proceed is to
instrument the performance (both where the CPU time goes and what's
doing allocations)? That was also suggested earlier in the thread, IIRC.
_______________________________________________
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