4 ms·
I love Swift but had to stop every time before getting serious for several reasons. As a language it’s just amazing. But whenever it’s come to performance on t
by jmaker 2y ago
I love Swift but had to stop every time before getting serious for several reasons. As a language it’s just amazing.
But whenever it’s come to performance on the backend, it would be not enough by a large margin. Take JSON serialization for instance, even using a yyjson wrapper it’s been nowhere near the original C performance, slower than Jackson, nlohmann::json, Go’s stdlib, and serde of course. I tried several Swift libraries. Model definition for custom deserializers alone for the few common ISO timestamp representations is a bit cumbersome but bearable. With some other formats and protocols I use, Swift is similarly underwhelming. Logging takes a large toll in performance as well, regardless of what a library appears to suggest when speaking of “efficiency.” I just can’t seem to squeeze out enough performance out of Swift. Async Postgres IO was quite good until I ramped up the load. TechEmpower benchmarks place Vapor relatively low. I get much better performance from low-effort Spring on Kotlin, needless to mention more performant backend frameworks.
Then the IDE story is very bleak. While I’m on Macs, Xcode just doesn’t cut it for me to be productive. Jetbrains discontinued their dedicated IDE and their Vscode pendent is still experimental. Vscode proper support for Swift is not really worth mentioning in my opinion. So I’m basically left with Xcode as an IDE for Swift.
I so dearly wanted to introduce Swift on the backend at my company but that’s just unrealistic right now.
- jcelerier 2y ago> slower than [...] nlohmann::json considering that nlohmann::json not even a performance-oriented json library, generally benchmarking at 20% of the performance of RapidJSON (which itself is not even close to the fastest you can reach in C++) that's... scary
- pourred 2y agoI noticed the same thing. Either Swift performances are atrocious, or I'm missing something. Just the other day I was trying to sort a large array of strings in Swift and it was painfully slow. A 3 lines Python script managed to sort the same dataset _at least_ 10x faster.
- _rend 2y agoI think it'd be curious to see the code, some example strings, and whether or not you compiled with optimizations enabled — if you're willing to share. There's no reason for this to have been the case.
- pourred 2y agoHere you go: https://pastebin.com/iemfTkzx https://pastebin.com/iemfTkzx As a dataset, I just use find to generate a list of paths from the file system: find / > large.txt I tested with Swift 5.7 and 5.9, and Python is always between 4x and 10x faster.
- bhokbah 2y agoswift strings handles unicode
- mannuch 2y agoHow recent were your experiences? The server-side Swift ecosystem has matured over the past few years, with specific attention from teams at Apple. For example, regarding JSON, there has been a rewrite of the JSON encoder/decoder that results in a 200% - 500% speed up in deserialization! You can read about the (still ongoing) improvements to Foundation at https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation Regarding logging, Apple has been pushing the development of community around the swift-log package at https://github.com/apple/swift-log https://github.com/apple/swift-log. Maybe you’ve seen this, but just wanted to share! One last thing: the Swift VSCode extension is actually really good! Not sure when you used it last, but I’ve been using it on a regular basis and it’s been great — and is only getting better. Here’s the link to the extension if you’re curious: https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi... It’s true that Swift has had its various issues, but there’s a very real push by the core team and community to bring the language to new heights and places. Cross-platform support is getting better and better (check out what The Browser Company is doing with Swift on Windows) and a big source of performance bottlenecks are being addressed with the development of non-copyable and non-escaping types (Rust-like move-only types)! Sorry that’s a lot, but I just wanted to point out that there’s a lot of hope in Swift and really interesting things are happening for the project!
- jmaker 2y agoMy recollection is as recent as a few months ago. Well I guess I’ll have to take another go at it this month, hopefully. I used three or four different JSON libraries aside from Foundation, including as I mentioned the quite popular yyjson wrapper which I expected to be on par with the pure C implementation. I’m out of the loop with the Swift ecosystem at the moment, can’t recall all the names. I experimented with several logger implementations, likely to have used the one you’re suggesting. Thanks for pointing it out. With the Vscode extension and the language server I suppose I had very palatable experience. It just didn’t work most of the time until I’d recompile the projects. Setting it up was a bit annoying as well, no build tool chain automations for project imports and setup, had to do the setup by hand. If I recall correctly, with one project an unpleasant issue I had was with the Swift Package Manager and CocoaPods, the Vscode extension wouldn’t recognize the project structure, and I ended up setting up a CMake project, good I have an affinity for CMake, and exporting it. But Xcode did just alright with it. So I just went back to Xcode for all my Swift projects. I think a plain SPM project actually got properly recognized in Vscode, but lots of dependencies are beyond SPM, which incidentally is also quite a significant annoyance in the Swift ecosystem. I wish Swift enjoyed more attention, like .NET has been having. Oh and in terms of documentation I feel Swift is nowhere near .NET, even though the setting is comparable. Referring to your closing remark, I don’t feel like that’s a lot, it’s a pleasure to learn more about Swift’s ecosystem, so thanks for taking your time to reply and providing extra context.
- pjmlp 2y agoSame applies on the memory management front, while it is understandable the decision they have made, for compatibility with Objective-C frameworks and runtime, most tracing GCs with 20+ years deployment experience are still faster than Swift on server workloads. And it is worth remembering that Objective-C only got ARC, because adding a tracing GC was a failure, given C semantics, and most applications being prone to crashes, when the GC got pointers wrong, thus automating retain/release pairs was a much safer approach.