Re: Performance problem with GC enabled
Re: Performance problem with GC enabled
- Subject: Re: Performance problem with GC enabled
- From: "Sean McBride" <email@hidden>
- Date: Sat, 14 Mar 2009 14:17:09 -0400
Paul Sanders (email@hidden) on 2009-03-14 6:29 AM said:
>I'm sorry Bill, but the more I hear about GC and in particular the
>difficulties of using it with malloc'd memory the gladder I am not to be
>using it.
My unsolicited 2ยข: :)
I am happy that the GC implementation keeps GC memory and malloc memory
separate. It makes using C/C++ libraries in your GC Cocoa app much
easier. Such libraries expect malloc to work the usual way, and would
likely need all kinds of changes were malloc's behaviour changed. I
work on a GC Cocoa app that uses several C and C++ libraries. It has
not been difficult to integrate them. In fact, I spent more time
retrofitting Obj-C libraries that were written to support retain-release only.
I have found it much more pleasurable to work in GC, and would not go back!
The biggest problems I have encountered are:
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.
2) premature collection wrt inner pointers. Easily fixed by grepping
for bytes|mutableBytes|fileSystemRepresentation|bitmapData and
defensively sprinkling some [obj self] messages around.
3) NSPersistentDocument + GC + Core Data's SQL store don't work
together. So I'm stuck with the XML store. :(
4) Universal Binary testing. Rosetta does not support GC. This means
that your unit tests can't run in Rosetta, like they can and do with
retain-release. Easily fixed by scrounging up a real PPC from somewhere.
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.
Sean
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden