3 ms·
How is the performance? Vapor's is terrible, which combined with the small ecosystem makes it a bad choice for backend.
by Zababa 5y ago
How is the performance? Vapor's is terrible, which combined with the small ecosystem makes it a bad choice for backend.
- still_grokking 5y agoIs this the reason IBM stopped its Swift on the server endeavors?
- smoldesu 5y agoPossibly one of them. Swift has just generally had a confusing, lopsided development cycle that has made it extremely hard to build larger/more-abstracted systems on top of it. I'm not quite so sure what breakage looks like these days, but the language only got null-checking a few months ago. I do hope they lay out more groundwork before making the push to non-Apple platforms.
- Redoubts 5y ago> the language only got null-checking a few months ago. ???
- user-the-name 5y ago> but the language only got null-checking a few months ago Are we talking about the same language?
- Zababa 5y agoThere are a few things here https://www.infoq.com/news/2020/01/ibm-stop-work-swift-server/ https://www.infoq.com/news/2020/01/ibm-stop-work-swift-serve.... From what I remember when it was announced, the small ecosystem was mentioned, but not the performance.
- WSSP 5y agoout of curiosity what does terrible means relative to other web server frameworks, and any idea what explains it? I would expect a Swift web framework has at least the potential to be performant
- Zababa 5y ago"terrible" here means within the ballark of Express and usually lower than Phoenix (the Elixir web framework), far slower than Go, and than most Java framework. The source is the TechEmpower framework benchmarks, with the caveat that Vapor isn't in all the categories, and the usual benchmarks caveat. For why it's not performant, I don't know precisely. Part of it may be because people don't use it a lot on the server side so it's not as optimized as the others. From what I've heard, Swift was also optimized for low memory usage rather than raw speed. Outside of that, I don't know. I would expect it to be around Go.
- WSSP 5y ago> From what I've heard, Swift was also optimized for low memory usage rather than raw speed at a 1000 foot view, Swift inherits its reference counting system from Objective-C, meaning objects are freed immediately when their retain count goes to zero; vs a tracing GC releasing many objects whenever a tracing cycle runs. maintaining reference counts also adds a cost that a different GC approach could avoid. it's true that Swift will maintain a lower memory footprint, potentially at the cost of lower throughput I would be a little surprised if that explains the bulk of a performance difference though, vs Swift frameworks being newer and less optimized
- Zababa 5y agoThank you for the explanation