Re:Swift is not
by adamnemecek on Wednesday June 04, 2014 @08:21PM
(#7849358)
These tests are meaningless without comparing the produced assembly (maybe the obj-c compiler is very well optimized since they've been doing that for quite a while now) and even then these microscopic tests don't really tell you much about performance in real scenarios. Swift has the advantage, as far as performance goes, that methods are not dispatched dynamically. In obj-c, every single time you call a method, you call objc_msgSend which executes at least 12 (IIRC) additional instructions (or more, depending on the situation). Plus as far as I know, not all objects are heap allocated which will also make things faster.
[ Parent
| on HN ]
I'd go further: Never trust a benchmark you can't run yourself. That goes for Apple's, and it appears to go for the ones in this post as well.
And microbenchmarks (and it doesn't get much more micro than "loop without doing anything") in particular have always been very poor predictors of real performance in my experience. They can be useful when trying to improve a specific area, but they should not be used for bold pronouncements.
Well, Apple is known for misleading benchmarks, and that guy is not.
I don't think it really matters what reputation anyone has, if you throw benchmarks out into the world and make claims about them, you should throw the code out too so people can repeat it and find flaws.
I'm not suggesting malicious intent at all here. People make mistakes, and contrary to what seems to be popular opinion, good benchmarks are hard.
Re:Swift is not
by AshleysBrain on Wednesday June 04, 2014 @08:45PM
(#7849467)
Examining assembly is especially important since mature optimisers are very good at eliminating code. A loop to assign the same variable a million times obviously has no side effects beyond the first assignment so the loop could easily be removed entirely.
Yeah but "C" is a subset of objective C and the idea is that tight code generally gets written in C without the dynamic dispatch. So comparing Swift to objc_msgsend seems to be a conscious misunderstanding of Objective"C".
Re:Swift is not
by adamnemecek on Wednesday June 04, 2014 @08:41PM
(#7849450)
I'm not sure I understand what you are trying to say. What do you mean by "the idea is that tight code generally gets written in C"?
He means that the performance intensive portion of Objective C programs (the tight loops, aka the 10% of the code that your code spends 90% of its time in, or whatever) are written in the subset of Objective C closer to C. E.g. they avoid dynamic dispatch in favor of static dispatch.
I'm not an Objective C programmer unless I can avoid it (C++ most days) so I can't really say if he's right or not. (Though, if I had to guess, I'd say he is)
Here's some assembly, if you're curious
https://gist.github.com/koke/553424954b16d65d1cb9
Method dispatch tends to not be a major factor in ObjC performance.
Re:Swift is not
by adamnemecek on Wednesday June 04, 2014 @08:38PM
(#7849438)
I'm inclined to disagree and this article seems to disagree as well http://it.toolbox.com/blogs/macsploitation/bypassing-objecti...
(it's not a great test but it's a test)
Given I've found some other articles that claim that it's not that slow but none of them really present any data.
I guess that it depends on your definition of "major factor".
Yes, if you were doing a quick sort and each op required a msgsend it'd be a factor. But you'd have to be crazy to write code like that. This is why there are a lot of C apis that Apple has written that you call and bridge with ObjC.
With Swift you can't do that. You have to wrap the calls and generate bridge headers. What a pain.
Re:Swift is not
by adamnemecek on Wednesday June 04, 2014 @08:56PM
(#7849522)
Are you surprised that a language that's officially 2 days old has worse support than a language that they've been using for the last maybe 25 years?
Do you have an application where message sending is a performance bottleneck?
Re:Swift is not
by adamnemecek on Wednesday June 04, 2014 @08:51PM
(#7849494)
Whether it is a bottleneck or not is a different question.
I think mpweiher's point was that in normal Objective-C applications, the fact that message sending is slow is irrelevant. Yes, it is slower than a C function call, but it's rare that it is an issue in real code. When it was a problem before, in something unusual like your article's heavy tree traversal, you'd inline the code or drop down to C. But that was fairly rare. Apple has also improved objc_msgsend within the past few years.
Re:Swift is not
by adamnemecek on Wednesday June 04, 2014 @09:07PM
(#7849581)
My wild guess is that with Swift, Apple is trying to get a more lightweight language not due to performance issues but due to battery consumption. I think that around 40% of CPU time of your average obj-c app is spent in objc_msgSend. That is potentially a lot of power essentially wasted.