Using alternates besides JSONDecoder for deserialization

[michaeleisel]

ZippyJSON (a framework that I created), is a 3-4x faster version of JSONDecoder. Using it could be a big speed boost for consumers. However, the customization provided by #28 doesn't allow for anything besides JSONDecoder (or a subclass of it). This makes it difficult to use ZippyJSON because alternate implementations are best not to subclass it to ensure good performance. Here are some possibilities:

• Allow users to pass in anything that implements TopLevelDecoder, and not just JSONDecoder
• Mention performance wins from using a custom implementation like ZippyJSON
• Simply use ZippyJSON behind the scenes by default

[michaeleisel]

To be clear, a well-written binary decoder/encoder would be faster, but I don't know if one exists right now (e.g. a fast MessagePack encoder/decoder)

[RamblinWreck77]

This would be cool! I've been keeping an eye on ZippyJSON for a while. Being able to speedup Disk reads as well would be a serious +1 for switching.

[idolize]

Yeah, I'm interested in using https://github.com/christophhagen/BinaryCodable for larger file writes.

[idolize]

FYI for those interested - I made a fork here that allows you to conform any custom encoder/decoder to the DiskEncoder or DiskDecoder protocols and use those instead with any of the built in Disk functions.

[michaeleisel]

What about the TopLevelDecoder protocol, can we leverage that here

[idolize]

@michaeleisel it's probably possible, but I had issues getting the compiler happy when I tried (admittedly I didn't spent a lot of time on it)