TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Swift Performance: Too Slow for Production

46 点作者 jipumarino超过 10 年前

9 条评论

mnem超过 10 年前
I hacked together a quick reproduction of this since the author didn&#x27;t provide any working code. I don&#x27;t really know Swift and my Objective-C skills are pretty rusty at the moment, but it compiles and show similar performance characteristics: <a href="https://github.com/mnem/swift-json-speedtests" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mnem&#x2F;swift-json-speedtests</a><p>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.<p>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&#x27;s necessary for speed reasons - although Obj-C is not uniformly faster than Swift as noted in other articles.
antimagic超过 10 年前
I find posts like this nearly entirely lacking in interest. There was so much <i>attitude</i> 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 <i>why</i> the various permutations had the performance that they did. We would then have a much stronger understanding of where Swift&#x27;s performance is at, instead of looking at a series of not exactly equivalent benchmarks that leave us wondering if we&#x27;re not just seeing an artifact of the differences in the benchmark code as opposed to differences in real-world performance.<p>I for one would not be changing my approach based on this post. I <i>might</i> start doing some disassembly if I was writing performance sensitive production code in Swift, but that would be about it.
jerf超过 10 年前
<i>Cough</i> When it comes to describing languages, there&#x27;s a set of words you should just consider vacuous throat-clearing until <i>proved</i> otherwise. This includes &quot;fast&quot;, &quot;powerful&quot;, &quot;robust&quot;, &quot;easy to [pretty much anything]&quot;, &quot;featureful&quot;, and a few others. Why is this? It isn&#x27;t because it&#x27;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&#x27;s because <i>every</i> language always claims it.<p>Also, &quot;fast as C&quot; is a slippery little thing; anything can be fast as C on some benchmark with an optimization for that benchmark, being <i>reliably</i> as fast as C and being able to engineer in the confidence that something is as &quot;fast as C&quot; all the time is quite another. Witness the number of people who will vigorously claim that Javascript implementations are &quot;as fast as C&quot;, despite in reality not being anywhere near that except in the aforementioned carefully-engineered benchmarks. <i>Especially</i> beware of &quot;adding integers in an array&quot;. That&#x27;s easy to optimize and nowadays says little since everyone optimizes for that case, knowing it&#x27;s going to be benchmarked.<p>In other news, the latest web framework is &quot;easy to use&quot; and &quot;powerful&quot; and probably &quot;MVC&quot;. This is just throat clearing, not a description anymore, because nearly everything is &quot;easy to use&quot; and &quot;powerful&quot; and &quot;MVC&quot;. Also, half the libraries posted to &#x2F;r&#x2F;$LANGUAGE are &quot;A simple, powerful library for X&quot;, which probably translates to &quot;A library I spent about 4 hours on&quot; rather than any sort of increased probability of it being either simple or powerful.
dagw超过 10 年前
Even as Python programmer I find the boast &quot;2.6x faster than Objective-C and 8.4x faster than Python 2.7&quot; 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.
评论 #8729175 未加载
Tloewald超过 10 年前
Here&#x27;s a different comparison for what it&#x27;s worth<p><a href="http://www.jessesquires.com/apples-to-apples-part-two/" rel="nofollow">http:&#x2F;&#x2F;www.jessesquires.com&#x2F;apples-to-apples-part-two&#x2F;</a>
评论 #8728980 未加载
mikhailt超过 10 年前
Too Slow for Production _for now_.<p>Swift hasn&#x27;t even been out for a year. Look at the progress it made since summer, it sped up a lot in certain parts.<p>Just file a radar on what&#x27;s slow and they&#x27;ll fix it.<p>Apple intentionally is shipping Swift as is to get devs ready and start planning for the next five years.
JamesBaxter超过 10 年前
I&#x27;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&#x27;t want to invest time learning something that&#x27;s on its way out.
评论 #8728962 未加载
jipumarino超过 10 年前
I haven&#x27;t tried Swift yet, so I&#x27;m posting this just to know what other experiences people have.
评论 #8729034 未加载
samnardoni超过 10 年前
Why not profile and see where the time is actually going? Slow JSON parsing? Slow I&#x2F;O?
评论 #8728991 未加载