
Swift Performance: Too Slow for Production - jipumarino
http://blog.sudeium.com/2014/12/10/swift-performance-too-slow-for-production/
======
mnem
I hacked together a quick reproduction of this since the author didn't provide
any working code. I don't really know Swift and my Objective-C skills are
pretty rusty at the moment, but it compiles and show similar performance
characteristics: [https://github.com/mnem/swift-json-
speedtests](https://github.com/mnem/swift-json-speedtests)

The initial Swift version the author created uses a third party library for
wrapping the JSON decoding and that library appears to create a metric shit
ton (technical term) of short lived objects whilst performing its magic. I
cobbled together a less memory insane version (likely similar to the one
described as Obj-C in Swift - although I disagree with that description) which
is an order of magnitude faster. Finally there is an Objective-C version which
is an order of magnitude faster again. All tests were running on an iPhone 5s
in release mode.

Decoding JSON is an annoying task for most languages. That Swift decodes half
a megabyte of JSON in a tenth of a second is a reasonable trade off, for me,
when comparing it to the verbosity and occasional fiddlyness of working with
Obj-C. It was quite nice to see how simple it was to mix Swift and Obj-C as I
was creating this, so that suggests little downside to using Swift for the
mundane tasks and coding specific bits in Obj-C when that's necessary for
speed reasons - although Obj-C is not uniformly faster than Swift as noted in
other articles.

------
antimagic
I find posts like this nearly entirely lacking in interest. There was so much
_attitude_ and not near enough actual analysis. A much stronger post would
have actually disassembled the resulting code in each of the different
configurations, and looked to see _why_ the various permutations had the
performance that they did. We would then have a much stronger understanding of
where Swift's performance is at, instead of looking at a series of not exactly
equivalent benchmarks that leave us wondering if we're not just seeing an
artifact of the differences in the benchmark code as opposed to differences in
real-world performance.

I for one would not be changing my approach based on this post. I _might_
start doing some disassembly if I was writing performance sensitive production
code in Swift, but that would be about it.

------
jerf
_Cough_ When it comes to describing languages, there's a set of words you
should just consider vacuous throat-clearing until _proved_ otherwise. This
includes "fast", "powerful", "robust", "easy to [pretty much anything]",
"featureful", and a few others. Why is this? It isn't because it's impossible
for any of these things to be true; all of them have been true of some
language somewhere, even on initial release. It's because _every_ language
always claims it.

Also, "fast as C" is a slippery little thing; anything can be fast as C on
some benchmark with an optimization for that benchmark, being _reliably_ as
fast as C and being able to engineer in the confidence that something is as
"fast as C" all the time is quite another. Witness the number of people who
will vigorously claim that Javascript implementations are "as fast as C",
despite in reality not being anywhere near that except in the aforementioned
carefully-engineered benchmarks. _Especially_ beware of "adding integers in an
array". That's easy to optimize and nowadays says little since everyone
optimizes for that case, knowing it's going to be benchmarked.

In other news, the latest web framework is "easy to use" and "powerful" and
probably "MVC". This is just throat clearing, not a description anymore,
because nearly everything is "easy to use" and "powerful" and "MVC". Also,
half the libraries posted to /r/$LANGUAGE are "A simple, powerful library for
X", which probably translates to "A library I spent about 4 hours on" rather
than any sort of increased probability of it being either simple or powerful.

------
dagw
Even as Python programmer I find the boast "2.6x faster than Objective-C and
8.4x faster than Python 2.7" pretty bizarre. So Objective-C is a statically
typed, compiled, C superset and still only 3.5x faster than Python? That is
not really something to be proud of.

~~~
hyperpape
Not an Objective-C programmer, but while includes static typing, it's also
very dynamic. It uses a message-sending paradigm and you can construct
messages at run-time from strings.

I believe Smalltalk is as about as much of an influence as C.

Lots of Objective-C programmers actively dislike Swift because it's so static.

------
Tloewald
Here's a different comparison for what it's worth

[http://www.jessesquires.com/apples-to-apples-part-
two/](http://www.jessesquires.com/apples-to-apples-part-two/)

~~~
vhbit
The point is that author of original post was unable to get it compile with
optimization turned on because of internal compiler errors. So yep, Swift can
be faster but so far you must be lucky enough to get it compiled.

So... Main conclusion is that Swift is not production ready yet.

------
mikhailt
Too Slow for Production _for now_.

Swift hasn't even been out for a year. Look at the progress it made since
summer, it sped up a lot in certain parts.

Just file a radar on what's slow and they'll fix it.

Apple intentionally is shipping Swift as is to get devs ready and start
planning for the next five years.

------
JamesBaxter
I'm currently deciding whether to start a project in Swift or Objective-C, I
know very little about either, for learning purposes Objective C has the edge
but I don't want to invest time learning something that's on its way out.

~~~
esaym
I doubt Objective C is on its way out...

~~~
mikhailt
Why not? This is Apple we're talking about, they're famous for getting rid of
older stuff.

A lot of experienced Apple developers do not expect Apple to support two
languages for a long time. With all the noise Apple made about Swift, it will
be getting more TLC than Obj-C and eventually, Obj-C will not be supported
anymore.

We're not talking about a few years, we're talking maybe Carbon>Cocoa style, 5
years before Apple starts warning devs that Obj-C would be phased out in
several years.

------
jipumarino
I haven't tried Swift yet, so I'm posting this just to know what other
experiences people have.

~~~
photograve
I also encounter binary size issue like 10 times bigger than the same program
in ObjC!

------
samnardoni
Why not profile and see where the time is actually going? Slow JSON parsing?
Slow I/O?

~~~
aethe
Blog author here. I actually did: the vast majority of time is spent in the
Swift Runtime. The JSON parsing is via NSJSONSerialization, which is an Apple
library written in Objective-C, and it's fast. I'm not measuring IO, I'm only
measuring the time spent turning the NSDictionary objects that come back from
NSJSONSerialization into my model objects.

I didn't spend a huge amount of time profiling this though, since it's very
early days in my project and it'd take me less time to just rewrite what I'd
done so far in a language that I know works.

