If you’re like me your development cycle goes something like this
- Write some code
- Write some more code
- Discover that code is getting messy
- Refactor the code when I get around to it
- Run unit tests and check that things still work
- Back to writing more code
This kinda works, especially if you have lots of automated tests (I must confess I have too few), but one of the things that often gets missed is performance testing. I made this mistake with DropSync recently, having let several months go by in between performance tests. Oops, when I ran the leaks performance tool I found one rather nasty leak. If I’d done this after every refactoring I would have found it really quickly, but because I’d made so many changes it was hard to narrow down the cause of the leak. Finding the object responsible was easy (the leaks tool is really good for this), but I spent an embarrasing number of hours staring at code until I finally discovered the cause, an incorrect property declaration for a nib object.
1 2 3 4
Apart from the fact that I didn’t really need a property declaration in this case, it should have been declared as (assign) since this reflects what the nib loading machinery on OSX does anyway. If I’d kept the (retain) I should have explicitly released the object in my dealloc method.