> A tiny, somewhat extreme example: Swift allocates local variables on the heap. (...)
Have you ever encountered a local variable that spuriously didn't get stack promoted? I haven't. As I said elsewhere, I regularly read the generated code for my hot loops. Also, when profiling with Instruments, I have never been surprised by a heap allocated local variable that didn't escape. I also don't see why stack promotion theoretically would be a less precise analysis then doing it the other way around. I imagine that if the optimizer misses to promote a local variable, it would be a bug in the same way it would be a bug if an escaping local variable spuriously didn't get boxed (for compilers working the other way). Just that it won't fail at runtime, which might increase the potential for undiscovered bugs. But again, have you ever been bitten by this?
> And of course generics are implemented via witness tables, so indirect dispatch at roughly similar costs to objc_msgSend()
Generic types are opportunistically specialized and in my experience, the optimizer has gotten a bit better in that regard. I find that a nice compromise between C++ and, say, Java. You can also influence the optimizer's decision with various not-yet-stable annotations (@specialized, for example). Sure, if you want to write reliably fast generic code in Swift, you need to know a few things. None of the above is possible in Objective-C, though, because of its type system.
> I just saw something about blocks always causing heap allocations (and this is corroborated by an attempt someone made to port some HTTP parsing code from C to Swift. Even with max. optimizations and inline craziness, it was ~3x slower).
If by blocks, you mean closures, then yes, they are heap allocated if they escape. For non-escaping closures, there is always a way to force an inline unless you pass them to compiled third-party code. Cross-module optimization is an area that is still being worked on. Without knowing anything about the code in the benchmark, from your description, it sounds to me that there is unused potential for optimizations, either by making the code more idiomatic and/or by using one or two annotations. Which brings me to my last point.
> What benchmarks are you looking at?? While it wouldn't be true that I've never seen a Swift advantage, it's pretty close to never.
Do you have links? Not that I looked too thoroughly, but I have never encountered a benchmark comparing Swift with Objective-C (or other languages?) that both (1) showed significant worse performance for Swift across the board and (2) that I trust. Most recent code I have seen that does not perform well could fairly easily be improved or would have to be rewritten in more idiomatic Swift. I specifically say most, since there certainly is still room for improvement, but in my experience it is nowhere as bad as your comment suggests.