To bring this back around to the concrete...
First -- a very hearty and public THANK YOU to Sean for filing quality
bug reports that often include minimal examples. The community has
definitely benefited from your contributions to the bug database!
On Mar 14, 2009, at 11:17 AM, Sean McBride wrote:
1) tools support. Finding classic leaks is basically impossible. :
( Recall that I use C and C++ libraries, and so have a need to do
classic leak checking. MallocDebug.app crashes with GC apps, and
'leaks' and Instruments find nothing but false positives.
The Object Graph instrument in Instruments does a pretty good job in
Leopard, though it has bugs, too. Turn off automatic sampling.
Most of what you are looking for in GC'd apps -- and, frankly, not
enough people look for in non-GC'd apps -- is unexpected growth of the
object graph or unexpected lack of shrinkage. The easiest way to
test for this is to repeat a task a couple of times. The object
graph *should* reach a stable state with the only growth being in
caches (though, hopefully not for repeated actions), logs, and any
other new data the app may have pulled in.
The 'heap' command can also give you an inventory of objects that
remain in existence within your app. Comparing the output of
repeated heap scans can do wonders for figuring out why an app is
growing. The object inventory section -- the part that lists the #
of any given type of object -- can generally be diff'd or opened in
FileMerge.
Frankly, though, the tools are a bit primitive in Leopard.... If
there are workflows that are broken for you, please file bugs.
However, if you have access to the Snow Leopard seeds, try and give a
test in SL before filing the bugs, if possible.
2) premature collection wrt inner pointers. Easily fixed by grepping
for bytes|mutableBytes|fileSystemRepresentation|bitmapData and
defensively sprinkling some [obj self] messages around.
That works. Patrick Beard took the suggestion of using the cleanup()
attribute and refactored it for use with GC. This works on Leopard.
This could be refactored for both GC and Non-GC by using [*object
release] and just dropping the objc_collect() -- it is only a hint
anyway. The -release will be ignored in GC, but the collector
doesn't know that. :)
#import <Foundation/Foundation.h>
#define GCKEEPALIVE __attribute__((cleanup(touchObject)))
static inline void touchObject(id *object) {
[*object self];
objc_collect(OBJC_COLLECT_IF_NEEDED);
}
int main (int argc, const char * argv[]) {
while (--argc) {
const char *arg = *++argv;
GCKEEPALIVE NSData *page = [NSData dataWithContentsOfURL:
[NSURL URLWithString:[NSString stringWithUTF8String:arg]]];
const char *bytes = [page bytes];
printf("page = %s\n", bytes);
}
return 0;
}
As for performance, I have encountered several instances where Shark
reports various libauto calls in the top 5, but I have not
investigated
due to other priorities.
Bug reports that contain performance issues are taken extremely
seriously. Bugs filed with -- even binary only -- relatively minimal
demonstrations of issues are captured and retested often to ensure
that we are, at the very least, not making the issue worse and, of
course, the goal is to make things go faster.
b.bum
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
