macOS If No Memory Leaks, Is It Good Enough for Memory Management?

[greatfree]

Dear all,

I am still a new programmer of Cocoa. In my program, at least right now, there are no memory leaks according to Instruments. Is it good enough for memory management?

What I designed is a TCP server which receives TCP messages. When I tested it, 200,000 XML were sent to it with a loop without any delays. Each XML had 800 bytes. In this case, no any memory leaks when testing it with Instruments. However, according to Activity Monitor, the consumed memory was increased from 17.9M to more than 400M. Immediately after the sending, the consumed memory started to be lowered until it was stopped to 100M. Was it normal? Why wasn't it 17.9M eventually?

Thanks so much for your help!

Best,
greatfree

 

[jiminaus]

Under which column of Activity Monitor did you observe this?

 

[greatfree]

Under which column of Activity Monitor did you observe this?

"Real Mem"

 

[gnasher729]

Dear all,

I am still a new programmer of Cocoa. In my program, at least right now, there are no memory leaks according to Instruments. Is it good enough for memory management?

What I designed is a TCP server which receives TCP messages. When I tested it, 200,000 XML were sent to it with a loop without any delays. Each XML had 800 bytes. In this case, no any memory leaks when testing it with Instruments. However, according to Activity Monitor, the consumed memory was increased from 17.9M to more than 400M. Immediately after the sending, the consumed memory started to be lowered until it was stopped to 100M. Was it normal? Why wasn't it 17.9M eventually?

What you describe sounds like you used one autorelease pool for all 200,000 messages. So if the 400 MB worries you, check whether you can drain the autorelease pool more often.

Why wasn't it 17.9MB eventually? Read Donald Knuth, The Art of Computer Programming, for an explanation It's very difficult to achieve, and it is not needed. If your Mac survived the app using 400 MB, then it will survive it using 100 MB. You could check what happens if you repeat the test three times. If it goes up to 500, down to 200, up to 600, down to 300, then you have a memory leak. If it always goes up to 400, down to 100, then it's fine.

 

[greatfree]

What you describe sounds like you used one autorelease pool for all 200,000 messages. So if the 400 MB worries you, check whether you can drain the autorelease pool more often.

Why wasn't it 17.9MB eventually? Read Donald Knuth, The Art of Computer Programming, for an explanation It's very difficult to achieve, and it is not needed. If your Mac survived the app using 400 MB, then it will survive it using 100 MB. You could check what happens if you repeat the test three times. If it goes up to 500, down to 200, up to 600, down to 300, then you have a memory leak. If it always goes up to 400, down to 100, then it's fine.

Dear gnasher729,

Each time, the results are the same. So my system is good for this case, right? I appreciate so much for your help!

 

[jiminaus]

Dear gnasher729,

Each time, the results are the same. So my system is good for this case, right? I appreciate so much for your help!

Is that every time you run it it's the same, or is that within the same run every time you receive a batch of 200,000 messages it's the same?

 

[greatfree]

Is that every time you run it it's the same, or is that within the same run every time you receive a batch of 200,000 messages it's the same?

The memory consuming status is the same each time when testing the server with 200,000 x 800 bytes (XML).

 

[gnasher729]

The memory consuming status is the same each time when testing the server with 200,000 x 800 bytes (XML).

The question was: Do you run the program three times, or do you run it once doing the same test three times? If you run the program three times with same results, that proves nothing. If you run the program once, perform the test, perform it again, perform it again, and your memory usage doesn't go up, then you are fine.

 

[lee1210]

There are a few different ways to think about this. Avoiding leaks is important because a leak means your memory use can grow unbounded and there's no way to reclaim the memory. You can still have unintended and unneeded growth that isn't strictly a leak. You could have an array that you continuously add to, for example. You *could* free all of the objects in the array, you have access to their pointers. But if your code never does this you can have unbounded growth without a true leak.

The real question isn't if no leaks is good enough. It's a start but you need to evaluate your memory use and see if you are ardently freeing things you don't need, and being efficient about how you store the things you do need.

-Lee