Consider replacing Foundation JSON encoder

[pokryfka]

Given that:

• Foundation JSON encoder/decoder has terrible performance on Linux (~10 times slower than PureJSONSwift and IkigaJSON
• swift-aws-lambda-runtime runs on Linux
• AWS Lambda handler does a lot of JSON decoding/encoding, including:
  • AWS Lambda Runtime API
  • JSON payloads delivered as String (APIGateway, DynamoDB, SNS, SQS, ...)
• most people dont change the default implementation assuming libraries are well tuned
• swift-aws-lambda-runtime performance is compared against other runtimes: https://www.twitch.tv/videos/661855412?t=04h53m04s
• as far as AWS Lambda is concerned, time literally costs money

Consider:

• replacing Foundation JSON encoder/decoder with PureJSONSwift or IkigaJSON
• recommend not to use it describing how to change it
• improve performance of Foundation JSON on Linux

Performance comparison:

From PureJSONSwift

Encoding

	macOS Swift 5.1	macOS Swift 5.2	Linux Swift 5.1	Linux Swift 5.2
Foundation	2.61s	2.62s	13.03s	12.52s
PureSwiftJSON	1.23s	1.25s	1.13s	1.05s
Speedup	~2x	~2x	~10x	~10x

Decoding

	macOS Swift 5.1	macOS Swift 5.2	Linux Swift 5.1	Linux Swift 5.2
Foundation	2.72s	3.04s	10.27s	10.65s
PureSwiftJSON	1.70s	1.72s	1.39s	1.16s
Speedup	~1.5x	~1.5x	~7x	~8x

From aws-xray-sdk-swift

(Average) results in seconds of EncodingTests from run 191224345

Test	test-macos (5.2.4)	test-linux (swift:5.2)	test-linux (swiftlang/swift:nightly-5.3-bionic)
testEncodingUsingFoundationJSON	0.884	2.258	2.293
testEncodingUsingIkigaJSON	0.518	0.262	0.248
testEncodingUsingPureSwiftJSON	0.497	0.347	0.328

[pokryfka]

@kneekey23 let's rerun the tests ;-)

[tomerd]

another thing that can help performance are static linking and/or making sure the zipfile only contains that absolutely necessary dylibs

[tomerd]

note: foundation JSON has been getting some performance boosts from @fabianfett and @spevans

swiftlang/swift-corelibs-foundation#2985
swiftlang/swift-corelibs-foundation#2987
swiftlang/swift-corelibs-foundation#2988
swiftlang/swift-corelibs-foundation#2989

[fabianfett]

@pokryfka given that the json performance has gotten better on Linux (if you use the main nightly build 😉), Foundation is a sensible preset, and there is an API to use your own Encoder/Decoder, do you think it is okay to close this issue?

[pokryfka]

@fabianfett thank you for the update and great to hear about the improvements!

Did you happen to make any performance tests before and after the changes?
for example using https://github.com/swift-extras/swift-extras-json/tree/main/PerfTests

I take your word that it improved :-), I think it is okay to close it.

On side note:
It's really great that Foundation JSON encoder/decoder performance improved and all swift-server should benefit.
In case of lambdas ... probably it will always be desirable to avoid Foundation to improve cold start (as much as possible, AHC and Soto use Foundation primarily for its URL and Date types).
(I think there's been some improvements with static linking on Linux side which might have helped a bit).

[spevans]

@pokryfka

In case of lambdas ... probably it will always be desirable to avoid Foundation to improve cold start

As you note static linking is definitely a help and obviously avoiding FoundationNetworking is a big win to avoid all of the libcurl dynamic libraries, but if you have any specific examples of it being slow it could possibly be investigated to see if there are any possible fixes - A new issue might be more appropriate though.

[pokryfka]

@pokryfka

In case of lambdas ... probably it will always be desirable to avoid Foundation to improve cold start

As you note static linking is definitely a help and obviously avoiding FoundationNetworking is a big win to avoid all of the libcurl dynamic libraries, but if you have any specific examples of it being slow it could possibly be investigated to see if there are any possible fixes - A new issue might be more appropriate though.

Agreed its not related to JSON performance as such.

From my limited testing some time ago dynamic loading had its penalty (I managed to statically link lambda function but not when using Foundation, I think there has been some updates in this area recently, planning to retest it).

The other issue was big size of the package, affecting bootstrapping by AWS during cold start; the biggest contributor here, bigger thanFoundation, is ICU as mentioned in https://github.com/swift-server/swift-aws-lambda-runtime#performance

[spevans]

If a binary is compiled using -static-executable then it should just be demand paged when used and should have quite a small cold start time.

ICU is mostly CLDR data used for uncicode/localisation/date time etc and is also used by the stdlib so will always be present. Its hard to shrink the data down but https://bugs.swift.org/browse/SR-9432 is probably one to watch as that may help in that direction.

Lastly, if libxml2 is used in anyway that uses the system version and at least on Ubuntu that is linked to the system ICU so actually two versions of ICU are then loaded into memory. Im not sure how its built on Amazon Linux (ldd would tell you) but vending a libxml2 as part of the swift toolchain linked to the vended ICU library would also help.