Re: Cocoa and dead-code stripping
Re: Cocoa and dead-code stripping
- Subject: Re: Cocoa and dead-code stripping
- From: Andrew Demkin <email@hidden>
- Date: Mon, 2 Jul 2007 13:34:25 -0700
Sorry to be the contrarian voice here, but dead-code stripping is
certainly possible for languages like Objective-C. It's one thing to
say it's not supported, or of lesser utility, but technically, it is
possible.
The way this would work is to have the development tools scan all
message selector references (and class literal references) and strip
all methods and classes that aren't referenced. This process would
repeat until the tool can no longer perform any more stripping. There
have been dynamic language implementations that behaved this way over
10+ years ago.
Of course, there's still the probability that some references won't
be known at compile-time, and for these methods and classes, a
tagging technique would be necessary to suppress the stripping.
So, whether dead-code stripping has much value in the common case, I
won't argue. But, to clear-up misconceptions here, it is possible.
HTH,
Andrew
On Jul 2, 2007, at 10:46 AM, Chris Hanson wrote:
On Jul 2, 2007, at 9:46 AM, Steve Christensen wrote:
I'm currently working with around 80 application plug-ins I've
written that link against this static library. All the plug-ins
use a number of features, plus each plug-in individually uses
various other features, depending on what it specifically
requires. So come link time, the linker strips out all the pieces
a particular plug-in isn't using. No magic there.
Going forward, I'm working to move my UI (and selected other
pieces) to Cocoa. Given the number of builds I'm doing, I'd still
like to compile the common pieces once, including the Cocoa bits.
I'd also like to, ideally, not have a bunch of never-used methods
left in the binary.
If I were writing a single application then the incremental size
of the code might not be a big deal. In my case it could be as
much as 80x the incremental size.
As others have pointed out, "dead-code stripping" is not possible
for Objective-C because given both the semantics and common use of
the language, the linker cannot prove that any particular method
will never be called -- and in fact some methods are likely to
never be invoked from other code in your plug-in, but as a result
of an action defined in a nib.
I'd like to point out a further issue with what you're considering,
however: You have thus far been able to get away with using a
static library for this approach only because you haven't been
using Objective-C. Once you start using Objective-C, you will not
be able to use a static library, because while C++ classes are not
objects and have little associated runtime data structure
associated with them, Objective-C classes are objects and are
associated with substantial runtime data structures. You cannot
have the same class registered in the same runtime multiple times,
which is what would happen if you had two plug-ins link your static
library and get loaded into the same application.
I cannot recommend strongly enough that you create a
"FooSupport.framework" that contains the common code for all of
your plug-ins, and that you link all of your plug-ins against that
in the future instead of against a static library. Long-term this
will be the most supportable solution, and it completely avoids the
"multiple versions of the same class registered" problem.
The main caveat to this approach is that you will need to carefully
design your framework's API so that you can maintain binary
compatibility from release to release, if users aren't required to
upgrade all of your plug-ins at once. This isn't all that hard
with Objective-C since the only area where it suffers the fragile
base class problem is in instance size (number and size of ivars);
you can add methods all you want without affecting binary
compatibility with your framework's clients, unlike with C++.
In summary:
* Dead-code stripping isn't meaningful for Objective-C.
* Static libraries, plug-ins, and Objective-C don't mix.
* Frameworks are great if you're aware of the fragile base class
problem take it into account in your API design.
Hope this helps!
-- Chris
_______________________________________________
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