Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Is this normal? Instruments
- Thread starter Avicenna
- Start date
- Sort by reaction score
Leaks!
Ignore the allocation row, focus on the leaks.
Click on the Leaks row, then dive in. You have some memory that you allocated at some point, probably via [[NSXXX alloc] init] that you do not have matched up with a [XXX release].
You must fix this problem. Memory management is a reasonably big issue. Take a deep breath and spend a few hours reading about it. Then jump back to your code.
BTW, kudos on actually taking the step of measuring your app's performance.
Ignore the allocation row, focus on the leaks.
Click on the Leaks row, then dive in. You have some memory that you allocated at some point, probably via [[NSXXX alloc] init] that you do not have matched up with a [XXX release].
You must fix this problem. Memory management is a reasonably big issue. Take a deep breath and spend a few hours reading about it. Then jump back to your code.
BTW, kudos on actually taking the step of measuring your app's performance.
I think you're approaching this wrong.
When learning how to use Instruments (or any diagnostic tool), start with a simple known-working program to run it on. It can be as simple as two buttons with two actions, each of which does nothing but NSLog() some text.
The purpose of this is so you can see how the tool behaves under normal circumstances. The goal is to learn how the tool works, not to learn how the program works.
After you know what simple normal operations look like, add some simple but measurable known-working code to the program. For example, make each button's action allocate an NSArray filled with 20 long NSStrings. One action uses the auto-releasing convenience method. The other action uses alloc & init, and does the release. Again, run the tool and see what things look like.
Next, introduce a specific bug: in the action that uses alloc & init, comment out the release. You now have a memory leak. Run the tool, test the program, and see what a leak looks like. You already know exactly what the program is doing: it's leaking in a specific way. You even know where the leak is. So use the tool to find the leak.
If there are other things you intend to use the tool for, follow the same approach. Start with a simple known-good program, make it do something that works which you can watch with the tool, then change the program to introduce a known bug and use the tool to find it.
Only after you know how the tool works, and the significance of what it tells you, should you try using the tool on a program whose goodness is suspect or unknown. Otherwise you don't know how to interpret what the tool tells you: you can't distinguish good from bad, because you don't know what either one really looks like.
When learning how to use Instruments (or any diagnostic tool), start with a simple known-working program to run it on. It can be as simple as two buttons with two actions, each of which does nothing but NSLog() some text.
The purpose of this is so you can see how the tool behaves under normal circumstances. The goal is to learn how the tool works, not to learn how the program works.
After you know what simple normal operations look like, add some simple but measurable known-working code to the program. For example, make each button's action allocate an NSArray filled with 20 long NSStrings. One action uses the auto-releasing convenience method. The other action uses alloc & init, and does the release. Again, run the tool and see what things look like.
Next, introduce a specific bug: in the action that uses alloc & init, comment out the release. You now have a memory leak. Run the tool, test the program, and see what a leak looks like. You already know exactly what the program is doing: it's leaking in a specific way. You even know where the leak is. So use the tool to find the leak.
If there are other things you intend to use the tool for, follow the same approach. Start with a simple known-good program, make it do something that works which you can watch with the tool, then change the program to introduce a known bug and use the tool to find it.
Only after you know how the tool works, and the significance of what it tells you, should you try using the tool on a program whose goodness is suspect or unknown. Otherwise you don't know how to interpret what the tool tells you: you can't distinguish good from bad, because you don't know what either one really looks like.