[swift-corelibs-dev] Third party license compatible libraries for JSON

Geordie Jay geojay at gmail.com
Sat Dec 5 02:59:52 CST 2015


I’m new to the concept of mailing lists so forgive me if this ends up in the wrong spot. I saw the current discussion about NSJSONSerialization and would like to add my 2c.


I recently decided to make a Non-Foundation (only standard library) replacement for NSJSONSerialization for the upcoming release of Swift as open source.


After a few iterations (I have rewritten the entire codebase about 3-4 times already). I am left with a result that is extremely fast with O(n) complexity (maybe the internal Int / Double initializers make it slower than this on certain inputs).


It is clean and modern, using a “JSON" Protocol to encapsulate all possible values to be serialized / deserialized. I had tried using an enum in the past, but this ultimately turned out to be an uglier (as in readability), slower, and relatively inflexible way of doing things. The use of a protocol means a deserialized Array is literally already an Array, an Int is an Int etc.


Its current speed is approximately 75% of NSJSONSerialization, regardless of input size. Note however this is with inline String decoding to UTF16 via String.UnicodeScalarView (and looking in Time Profiler shows that this step takes approximately 50% of the running time). I have used no non-standard lib code here, which, if you all agree, I would change to use CoreFoundation classes where necessary. The result should be on par with NSJSONSerialization in speed (possibly better), but with an indiomatic and strongly-typed output built on an easy-to-reason-about Swift codebase.


https://github.com/ephemer/strongly-json/tree/QuickJSON
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151205/a5192f04/attachment.html>


More information about the swift-corelibs-dev mailing list