4 ms·

On the github page https://github.com/xi-editor/xi-editor https://github.com/xi-editor/xi-editor: JSON. The protocol for front-end / back-end communication,

by mov_ 6y ago

On the github page https://github.com/xi-editor/xi-editor https://github.com/xi-editor/xi-editor: JSON. The protocol for front-end / back-end communication, as well as between the back-end and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual improvement in performance would be completely in the noise. Using JSON considerably lowers friction for developing plug-ins, as it’s available out of the box for most modern languages, and there are plenty of the libraries available for the other ones. 4 years later: The choice of JSON was controversial from the start. It did end up being a source of friction, but for surprising reasons. For one, JSON in Swift is shockingly slow. Surprising reasons?!

raphlinus 6y ago
Yes. In this discussion and on Reddit, people still talk about binary vs textual as the source of the problem, but I've argued (based on empirical data) that the lexical details are not the reason for the performance problems. Also, Swift is marketed as a fast language (also based on LLVM), yet in my measurements it's 20x to 50x slower than Rust for JSON processing. I found that surprising. Would you not?
- mov_ 6y ago
  I agree with you, it's weird that Swift JSON is so slow and binary isn't necessarily faster. My exasperation is you were surprised by JSON becoming an issue, when this was the most controversial design decision about the project. To me, it's completely unsurprising.
  - __s 6y ago
    They're saying the reasons were surprising, ie they expected it to be controversial for different reasons
- shakna 6y ago
  It wouldn't be especially surprising to me. JSON's parsing performance is difficult, whether or not the language doing the parsing is fast or not. There's a reason that there are almost always libraries claiming faster JSON performance, regardless of the language. Go is marketed as a fast language, and they're still trying to build a high performance JSON parser [0]. Parsing JSON will always be slower than most of the alternatives. [0] https://dave.cheney.net/high-performance-json.html https://dave.cheney.net/high-performance-json.html
- saagarjha 6y ago
  Swift’s slowness is kind of unfortunate, although I hear that there is work being gone to remove a lot of the lifetime cruft that was going in behind the scenes to make it slow. And unfortunately I think the primary motivation for Swift’s performance is driven by its primary application, which is UI development, so “good enough” performance usually works…
  - pjmlp 6y ago
    WWDC has a couple of talks regarding runtime improvements, and low level coding including unsafe style coding with Swift.
fluffything 6y ago
> Surprising reasons?! It is possible to write a blazing fast JSON serializer/deserializer on pretty much every programming language, and most languages have many of them. Swift does not, and it does not seem that it will have one in the near future. This is quite disappointing, taking into account that Swift is one of the 3 major-platform native languages (C# windows, swift macos, C on Linux). So yeah, it is quite surprising that the major platform language in one of the main platforms in use has extremely poor JSON support. Even more surprising is that there is no path forward to fix that. There are many pros/cons of using json, but this was a "non issue" (if it isn't fast enough, we can make it fast - turns out we cannot because the platform is controlled by Apple and they don't want to).

by mov_ 6y ago

raphlinus 6y ago

Yes. In this discussion and on Reddit, people still talk about binary vs textual as the source of the problem, but I've argued (based on empirical data) that the lexical details are not the reason for the performance problems. Also, Swift is marketed as a fast language (also based on LLVM), yet in my measurements it's 20x to 50x slower than Rust for JSON processing. I found that surprising. Would you not?

mov_ 6y ago
I agree with you, it's weird that Swift JSON is so slow and binary isn't necessarily faster. My exasperation is you were surprised by JSON becoming an issue, when this was the most controversial design decision about the project. To me, it's completely unsurprising.
- __s 6y ago
  They're saying the reasons were surprising, ie they expected it to be controversial for different reasons
shakna 6y ago
It wouldn't be especially surprising to me. JSON's parsing performance is difficult, whether or not the language doing the parsing is fast or not. There's a reason that there are almost always libraries claiming faster JSON performance, regardless of the language. Go is marketed as a fast language, and they're still trying to build a high performance JSON parser [0]. Parsing JSON will always be slower than most of the alternatives. [0] https://dave.cheney.net/high-performance-json.html https://dave.cheney.net/high-performance-json.html
saagarjha 6y ago
Swift’s slowness is kind of unfortunate, although I hear that there is work being gone to remove a lot of the lifetime cruft that was going in behind the scenes to make it slow. And unfortunately I think the primary motivation for Swift’s performance is driven by its primary application, which is UI development, so “good enough” performance usually works…
- pjmlp 6y ago
  WWDC has a couple of talks regarding runtime improvements, and low level coding including unsafe style coding with Swift.

fluffything 6y ago

> Surprising reasons?! It is possible to write a blazing fast JSON serializer/deserializer on pretty much every programming language, and most languages have many of them. Swift does not, and it does not seem that it will have one in the near future. This is quite disappointing, taking into account that Swift is one of the 3 major-platform native languages (C# windows, swift macos, C on Linux). So yeah, it is quite surprising that the major platform language in one of the main platforms in use has extremely poor JSON support. Even more surprising is that there is no path forward to fix that. There are many pros/cons of using json, but this was a "non issue" (if it isn't fast enough, we can make it fast - turns out we cannot because the platform is controlled by Apple and they don't want to).