← Back to context

Comment by littlestymaar

6 years ago

> get performance near the ballpark of C++ and family.

That's a bit of an overstatement, Swift isn't really in the same ballpark than C++. Its performance characteristics are more the like of a managed language.

In the ixi driver implementation[1], they ended-up with results comparable to JavaScript in terms of throughput[2], and C# in terms of latency [3].

[1]: https://github.com/ixy-languages/ixy-languages/blob/master/R...

[2]: https://github.com/ixy-languages/ixy-languages/raw/master/im...

[3]: https://github.com/ixy-languages/ixy-languages/raw/master/im...

The main problem with this challenge is that a) most Swift developers are more used to writing front-end code and b) the specific network card isn't available to everyone that would like to look into this problem (like people with MacBooks). So while this driver seems to spend 3/4 of it's time in retain/release and I see the word `class` everywhere and the word `inline` nowhere (while inline is used in the C version it's based on!) I just can't do anything to improve it's performance.

  • Yeah I had the same reaction. If you look at the source, it looks like they lean heavily on reference-types, which is a worst-case for Swift performance. Specifically running tight loops with reference-counted objects comes with a huge cost, which seems to be exactly what this code does. I would love to take a crack at optimizing it, but I can't run it on my system.

    Still, Swift definitely makes some compromises when it comes to performance. ARC is pretty costly in general (in terms of time, it's pretty cheap memory-wise), thanks to heavy use of atomic operations, and copy-on-write for value types has really nice properties as far as making it easy to write correct code, but it can result in unnecessary data duplication which is hard to optimize since you're basically at the mercy of the compiler to make it mode efficient.

    A lot of these problems have possible solutions which haven't been implemented yet - in the long term I'm curious how much performance could be improved since I think Swift really could be the "sweet spot" language in terms of performance and usability.