Mandrake.net

kaydell-leavitt asked: What do you think of garbage collection in Objective-C 2.0 for Mac (doesn't work for iOS)?

Well, I know that iOS is all ARC-based, but I have definitely noticed a lot of thigns where running in a non-memory starved situation that a lot of allocated memory tends to stick around indefinitely until you actually need it in another application.  The only thing that gives me reliable information about what memory my application is using that is legit is the Instruments application from inside of XCode.  Admittedly, I think that tool is simply fantastic, and an invaluable resource when doing any significant debugging.  

As far as whether or not garbage collection does the number one GC complaint I have with a language like, say, Java, I have yet to see GC end up doing something like lock my application up to a point where I am unable to do meaningful processing or user/UI interaction.  The only times I’ve seen that are when I end up pegging the CPU(s).  A great example of this is the introduction to NSOperationQueue in the Big Nerd Ranch book (this book, incidentally, is fantastic and I highly recommend it as well as their iOS programming book), where loading a couple hundred images pegs even my massive Mac Pro desktop (the default version sets a max number of simultaneous operations ,but that is BORING!  If you’re working through a book teaching you a programming language and you don’t change things up to try to learn a few more things, you’re doing it wrong!).

As far as comparing it to other versions of Objective C, I’m far too new to the language to gauge it well.

kaydell-leavitt asked: I went to try to answer your question about memory management in Mac OS X. I wanted to tell you that there is a new way of doing memory management called "ARC" which is short for "Automatic Reference Counting". I've read some really good things about it. It is reported to cut down a lot on both memory leaks and on crashes that are caused by using memory that has already been deallocated. -- Kaydell

Yes, I’m using ARC, the problem is it is not as magical as one would hope, and it was not clear (to me) when to do things like use __weak references (like when allocating a __block operation that you’re going to add to an NSOperationQueue).

Investigating Memory Management in OS X

As I’ve mentioned a few times, I’ve been trying to debug memory usage in an application running under OSX.  I’m pretty sure I’ve conquered all the memory leaks, but I’m still not 100% on what some of the definitions are, but here are some things I have learned:

1) Running inside the debugger from xcode (a.k.a. just go hit the big shiny ‘Run’ button or cmd+r takes about 50% more memory (or more) than without.

2) Running inside the profiler takes 3-4x as much memory as running normally.  This does not include all the truckload of memory that Instruments will allocate while storing every piece of transient memory that your application starts using.  (In my case, though my runtime memory is small, the amount that is transient while doing a lot of network i/o is large, and instruments gets very big, very quickly)

3) I still don’t really understand what Virtual Private Memory is.  I’m pretty sure I have solved all of my memory leak problems, but I can’t find anything that really explains that breakdown (from Activity Monitor) very well.

Some numbers (not including when run under instruments):

Time : Real Mem / Private Mem / Virtual Private Mem

In Debugger:
6:00 : 36.0 MB  / 5.8 MB
6:10 : 35.0 MB  / 7.4 MB
6:20 : 32.9 MB  / 8.2 MB      / 58.2 MB
6:30 : 36.4 MB  / 7.7 MB      / 61.4 MB <— shut down another application, memory increased
6:40 : 36.6 MB  / 10.0 MB     / 61.4 MB
6:50 : 37.3 MB  / 10.8 MB     / 62.4 MB
7:00 : 38.1 MB  / 9.3 MB      / 62.4 MB

Outside Debugger:

9:30 : 21.8 MB  / 6.8 MB      / 59.8 MB
10:00: 28.2 MB  / 11.8 MB     / 55.4 MB
10:30: 31.4 MB  / 12.5 MB     / 56.9 MB

After Bug Fix:

11:00: 21.1 MB  / 6.0 MB      / 60.3 MB
11:15: 23.3 MB  / 7.9 MB      / 61.1 MB
11:30  21.2 MB  / 8.0 MB      / 53.9 MB
 2:00: 30.0 MB  / 11.5 MB     / 60.1 MB
 2:30: 30.9 MB  / 10.3 MB     / 60.1 MB
 3:00: 31.3 MB  / 10.9 MB     / 61.1 MB
 3:30: 31.3 MB  / 10.9 MB     / 61.1 MB
 4:00: 31.3 MB  / 10.9 MB     / 61.1 MB
 4:30: 31.3 MB  / 10.9 MB     / 61.1 MB

I am pretty sure all the leaks are gone, but it seems like it doesn’t like to free memory once it is allocated very often, too.  Maybe someone who has more knowledge can comment?

NSTextView not thread safe

I had been tracking down all sorts of fun stuff only to discover that NSTextView is not thread safe.  I mean, I guess I shouldn’t be surprised.  Going to have to go through and make sure all of my UI elements are updated in the main thread instead of in any sub-threads right now.  In fact, I kind of want to push a lot of data updates back into the main thread.  I bet this solves all sorts of stupid problem I was having.

*sigh*

At least this explains a great many things.