Using alternates besides JSONDecoder for deserialization

saoudrizwan / Disk

Easily persist structs, images, and data on iOS

MIT License

3.1k stars 171 forks source link

Using alternates besides JSONDecoder for deserialization #81

Open michaeleisel opened 5 years ago

michaeleisel commented 5 years ago

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 https://github.com/saoudrizwan/Disk/pull/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 commented 5 years ago

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 commented 4 years ago

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 commented 9 months ago

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

idolize commented 7 months ago

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 commented 7 months ago

What about the TopLevelDecoder protocol, can we leverage that here

idolize commented 7 months ago

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