Just a question:
How do you rate the performance of Swift compared to Objective C? In real world scenarios. On mobile devices. As server-side language. On desktops.
It seems that Objective C in terms of speed is far better...
Regards
Speed and performance is a relative term.
If you're referring to raw execution speed, it's a matter of getting the number of ASM instructions down to as few as possible.
If you're referring to startup times, I don't have those numbers - but there are some demonstrations of Swift apps starting up on server-side 100x faster than Java apps.
If you're referring to developer speed, Swift is clearly the winner of Obj-C in many areas.
In terms of performance in the area of app stability (crashes) - Swift also is clearly a winner as whole categories of causes for bugs and crashes are eliminated (or heavily minimized) by built-in design of the language.
2 Likes
I can't think of a single circumstance in which Objective C has a performance upper hand. Do you have anything particular in mind?
Citation needed. "It seems" is not an accepted argument when talking about performance.
2 Likes
And I highly doubt that Swift is not as performant as Obj-C: See Redirect
There’s very little information around on the topic. But after a few weeks of research and experimentation I’ve managed to create a couple of libraries that can achieve the same speed as carefully optimized vectorized C code, whilst being concise and easy to use.
The question came up by reading “„iOS and macOS Performance Tuning... by Marcel Weiher. AW 2017.
He measured execution times of some examples of standard tasks (sorting, summing over arrays with for-each, reduce etc.) and compared them with Objective-C (using blocks) code and C code. Depending on the optimization level, the results produce at least an "Ouch!“experience.
As by the marketing experts at Apple showed that:
. Particularly this was not in all cases the whole truth.
Therefore my question. I had performance in terms of execution times in mind. To clarify that.
Most people you're talking to don't have this book. If you want us to be able to participate in this conversation, you're going to have to provide much more detail, such as:
- Precisely what code was being benchmarked?
- Perhaps he was comparing good ObjC code to "bad" Swift code.
- Perhaps he was comparing a situation in Swift prioritizes safety over performance. (Which it very commonly does, but usually not in a way that isn't circumventable if performance is critical. See
+vs&+,UnsafePointer, etc.
- What compiler versions was he using?
- What optimization levels were used?
- What were the results?
1 Like
I just wanted to know how as an experienced Swift user you can compare the performance with Objective C from your gut and just take a shot in the blue.
How to pose scientific questions correctly is well known to me. But that was not a scientific question, but a question for "how feels the performance to others subjectively) . When I find time, I will quote two or three examples from the book.
__
(Relaxed conversation isn't so much in demand here in the forum, is it? 
)
2 Likes
You know, unless you are writing performance critical code, when writing everyday software the performance is mainly bound to the quality of the code (whatever the language is) and the framework performance (which is not language dependent), so I doubt anyone can objectively answer that one feel faster than the other.
1 Like
Idk how it comes across text, but i'm totally relaxed. It's just hard to respond to "A book said something, what do you think about it?" Well, what did the book say?
If you're looking for anecdotes, then I'll toss mine in the ring: Swift is incomparably faster than ObjC, in situations where it's not just standing-in for ObjC. I.e. if you're making a small iOS app, most of your code is just interfacing with ObjC frameworks, which forces you to use classes and dynamic dispatch, even where they aren't your first choice.
But on the other hand, if you're writing a server app, you have full access to structs, generics, static dispatch, and other performance features that ObjC couldn't even come close to. Swift is competitive with Go and Rust in the new generation of web servers.
6 Likes
If Marcel was using blocks in his examples in 2017, that could have run into an issue at the time where blocks were always heap allocated unless inlined. That issue was fixed in a subsequent version of Swift.
If you find test cases where ObjC is faster than Swift, please file a bug so we can fix it :)
11 Likes
Anecdotally, as requested: I’ve found them to be similar.
Although in the case of Objective-C my high performance code has been essentially plain C, minimizing runtime and dynamic dispatch. Sometimes I’d have some ObjC++, which adds some indirection performance overhead and cognitive overhead.
In Swift I believe I can get similar performance with a lot less time and effort. I also rarely have to mix and match different languages or architectures.
On average with similar effort I’d expect Swift to be faster. Without thinking about performance when coding I’d expect Swift to be faster.
As an aside: when we removed the last of our performance sensitive ObjC code from our large mixed codebase we were all relieved. We replaced it with much less Swift code that was a lot more approachable to the whole team.
1 Like
I think that's a key point. At bottom, you still have raw pointers, bit manipulations and such available to you, so if you're going out of your way to optimize some code, both give you similar tools to work with.
I don't agree here: For me, the key point is wether Swift is actually fast.
There are some tendencies to belittle any critism, but I don't think lying to ourselves helps anybody.
As a matter of fact, performance seems to be no important concern for many applications nowadays, but there's one area that can really bug us developers, and where I heard lots of complaints:
Compilation speed of Swift is definitely not even in the same league as Go.
2 Likes
For sure, compilation times can be quite bad with Swift. But that doesn't mean Swift code performance is bad, it's just the developer experience of compiling code that is bad.
2 Likes
While thats true, one could also argue that the Go compiler doesn't do half the things that the Swift compiler does. Don't get me wrong, Swift compilation speed isn't great, but its definitely getting better.
The comparison with Go is an odd one too considering how vastly different the approaches to the languages are, it's like comparing a Ferrari to the Saturn V rocket, two modes of transport built for very different purposes with very different philosophies.
But thats getting off topic, just like @donny_wals said, this is about run time performance, not compilation performance.
1 Like
The last two answers imho are good examples of what is not going well when somebody criticizes an aspect of Swift:
Instead of saying "yes, let's improve compilation speed", the reaction is "that's not important" or "but it has to be that way".
I'd not say it's "just the developer experience of compiling code that is bad" - this an aspect that in many scenarios is much more important than run time performance.
Getting back to topic, I once had to rewrite a parser in Objective-C because the Swift version was terrible slow, and I knew from a similar task that solving the same problem in C would be good enough without any tweaking.
I'm pretty sure it would have been possible to get good performance from Swift as well - but that would have taken much more development time, and the result probably would be (fast but) ugly Swift.
As I understand the thread-starter, he just wanted to hear some stories like "we rewrote our $whatever in Swift, and it was n% faster than the original" - and it's telling something that nobody here had such experiences.
1 Like
This is a clear misrepresentation of both posts that you are talking about, which say
and
2 Likes
Where did anybody write "let's improve compilation speed"? I didn't claim the issue was gainsaid, just that it has been played down.
What's the problem with simply admitting shortcomings? Imho Davids attitude is much more productive: When somebody complains about a flaw, that is not an attack on Swift - it's an opportunity to make it better.
IMHO, they simply dismiss the topic because this is not the subject. The original message is about generated code speed.
If you want to talk about compilation time issue, there is probably much to say and many way to improve it, and I'm pretty sure the same people will be happy to talk about it in a dedicated thread.
3 Likes