> Le 29 juin 2016 à 01:01, Michael Peternell via swift-evolution > <swift-evolution@swift.org> a écrit : > > >> Am 29.06.2016 um 00:32 schrieb John McCall <rjmcc...@apple.com>: >> >> The decision to make class methods polymorphic by default was always >> premised on being able to undo that in obvious cases where methods are never >> overridden. Making a class public so that clients can use it shouldn't >> cause significant performance degradations just because you forgot to also >> write "final". >> >> John. > > I do care about performance. For this reason I don't want a fully dynamic > language. I disagree about the "significant performance degradations just > because you forgot to also write `final`". I mentioned "performance" in my > original post only because it would be the only convincing argument - if > there were indeed superior performance when using `final`. > > Of course, dynamic dispatch is much slower than static dispatch. But > optimized code does not spend much time dispatching. If a method takes 3 > seconds to complete, and from that 2 seconds are used for dynamically > dispatching method calls, then I would say that it has not been optimized for > performance yet. How would such a function look like? The function being > dynamically dispatched should probably not be statically dispatched but > inlined completely. And for the rare case that the dispatch type really makes > all the difference, it's always possible to `final`ize (or `private`ize) some > of the used methods.
Swift dynamic dispatch is not Obj-C dynamic dispatch. Talking about the cost of dynamic dispatch without real benchmark is premature optimization IMHO. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
