The linker is smart enough to get rid of frameworks that you don't actually use.
Félix > Le 5 janv. 2016 à 21:55:17, Charles Srstka via swift-evolution > <[email protected]> a écrit : > >> On Jan 5, 2016, at 8:29 PM, Greg Parker <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> On Jan 5, 2016, at 11:52 AM, Douglas Gregor <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> There are better mechanisms for this than +load. But one would have to >>>> deal with the dylib loading issue and the need to enumerate root classes >>>> to get to a complete implementation. Frankly, I don’t think this level of >>>> Objective-C runtime hackery is worth the effort, hence my suggestion to >>>> make the existing behavior explicit. >>> >>> Yeah, +load was just to throw together a quick-and-dirty demonstration, and >>> not what you’d actually use. You have a point about libraries and bundles; >>> you’d have to hook into that and rescan each time new code was dynamically >>> loaded. However, the enumeration of classes only seems to take around 0.001 >>> seconds, so I don’t think it’s terrible. >> >> Enumeration of classes is terrible: it forces the runtime to perform lots of >> work that it tries very hard to perform lazily otherwise. I would expect >> your measured cost to be much higher if you had linked to more high-level >> libraries (UIKit, MapKit, etc). > > That was my gut reaction to the idea also, when I had it, but it seems to run > pretty fast no matter what I do. I just tried dragging every framework from > /System/Library/Frameworks into the project, removing only the Java > frameworks, Kernel.framework, Message.framework, and vecLib.framework. Time > taken was 0.004260 seconds. > > It is, of course, ugly and hacky as hell, and that might make a pretty good > reason not to do it. :-/ What do you think about the other idea, of adding to > NSObject’s default implementation of +resolveInstanceMethod:? That *would* be > done lazily, and would avoid all the problems involving dynamically loaded > code. > > Charles > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
