You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SwiftyJSON currently uses LclJSONSerialization on Linux, as although JSONSerialization in Foundation is functionally equivalent, there are some remaining performance issues relating to serializing number types that need to be addressed.
Swift 3.1
Swift 3.1 gives us a 25-30% improvement in JSON serialization performance for LclJSONSerialization, compared to 3.0.2.
The reason: our Lcl implementation uses String(describing:) to convert these values to Strings, whereas Foundation uses a NumberFormatter (which is significantly slower). The Lcl method was not considered an acceptable solution in JSONSerialization, as it essentially delegates control over the output format to String.
A solution for Int / UInt types is being worked on by @ddunn2, who has a prototype which is showing promising results very close to performance of Lcl, but will not make it into 3.1.
We haven't tackled Double / Float yet - assuming David's algorithm is accepted, we may well be able to extend it to cover these types as well.
Benefit of bypassing SwiftyJSON
I saw around 10-20% performance improvement when using the new API introduced in #1025, in other words replacing response.send(json: JSON([“a": 1, “b": 2, “c": 3]))
with response.send(json: [“a": 1, “b": 2, “c": 3])
Parsing
I have not analyzed the parsing side. This needs work.
The text was updated successfully, but these errors were encountered:
Serialization
SwiftyJSON currently uses LclJSONSerialization on Linux, as although JSONSerialization in Foundation is functionally equivalent, there are some remaining performance issues relating to serializing number types that need to be addressed.
Swift 3.1
Swift 3.1 gives us a 25-30% improvement in JSON serialization performance for LclJSONSerialization, compared to 3.0.2.
apple/swift-corelibs-foundation#718 and apple/swift-corelibs-foundation#723 are included in Swift 3.1, and reduce the performance gap. In 3.1, Foundation is on-par for Strings, but still 2x slower for number types (Int, UInt, Float, Double).
The reason: our Lcl implementation uses
String(describing:)
to convert these values to Strings, whereas Foundation uses a NumberFormatter (which is significantly slower). The Lcl method was not considered an acceptable solution in JSONSerialization, as it essentially delegates control over the output format to String.A solution for Int / UInt types is being worked on by @ddunn2, who has a prototype which is showing promising results very close to performance of Lcl, but will not make it into 3.1.
We haven't tackled Double / Float yet - assuming David's algorithm is accepted, we may well be able to extend it to cover these types as well.
Benefit of bypassing SwiftyJSON
I saw around 10-20% performance improvement when using the new API introduced in #1025, in other words replacing
response.send(json: JSON([“a": 1, “b": 2, “c": 3]))
with
response.send(json: [“a": 1, “b": 2, “c": 3])
Parsing
I have not analyzed the parsing side. This needs work.
The text was updated successfully, but these errors were encountered: