Hacker News Reader

Comment by mov_ | Hacker News Reader

On the github page 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?!

View on HN

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?

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.

They're saying the reasons were surprising, ie they expected it to be controversial for different reasons

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

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…

WWDC has a couple of talks regarding runtime improvements, and low level coding including unsafe style coding with Swift.

> 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).

Reply on news.ycombinator.com