michaeleisel / zippyjson Goto Github PK
View Code? Open in Web Editor NEWA much faster version of JSONDecoder
License: Other
A much faster version of JSONDecoder
License: Other
Would like to use this on the server, and was wondering if there are any blockers. Thanks.
I am trying to extend Lottie-Ios with Zippy Json.
But when i use standard init: try ZippyJSONDecoder().decode(Animation.self, from: json)
It throws exception:
DecodingError
▿ valueNotFound : 2 elements
- .0 : Any
▿ .1 : Context
▿ codingPath : 2 elements
▿ 0 : JSONKey(stringValue: "layers", intValue: nil)
- stringValue : "layers"
- intValue : nil
▿ 1 : JSONKey(stringValue: "Index 1", intValue: 1)
- stringValue : "Index 1"
▿ intValue : Optional
- some : 1
- debugDescription : "Cannot get next value -- unkeyed container is at end."
- underlyingError : nil
JSON Attached
SpinnerLoader.json.zip
The proposal is to make ZippyJSONDecoder
conform to TopLevelDecoder
protocol from Combine
framework. This will allow to use ZippyJSON
in reactive publisher chaining:
URLSession.shared.dataTaskPublisher(for: request)
.map { $0.data }
.decode(type: Response.self, decoder: ZippyJSONDecoder()) // <----
.receive(subscriber: mySubscriber)
At first glance there is enough to add these lines to ZippyJSONDecoder.swift
as Apple did with JSONDecoder
:
@available(OSX 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *)
extension ZippyJSONDecoder: TopLevelDecoder {
public typealias Input = Data
}
I keep getting this error while my json doesn't appear to have no-ascii keys
https://gist.github.com/Kalzem/4c1483476693db06d4783d9243f68345
What can possibly trigger this error?
When I try to print the returned iterators on JNTCheck(iterator), this is what appears
I am seeing so many warnings in Xcode 11.2.
How can we fix that?
do you only parse as string and Bool?
var price: Int?
Swift.DecodingError.dataCorrupted(Swift.DecodingError.Context(codingPath: [LazyJSONKey(stringValue: "Index 0", intValue: 0), LazyJSONKey(stringValue: "price", intValue: nil)], debugDescription: "Parsed JSON number 2500 does not fit.", underlyingError: nil))
Hello @michaeleisel
Firstly I appreciate the time you've invested into OSS and wanna say thank you for this library.
Was playing a bit with 1.2.6 hoping to replace the default JSONDecoder
and compare performance, but I'm getting this console warning:
[ZippyJSONDecoder] Warning: fell back to using Apple's JSONDecoder.
Reason: This library was not compiled with the necessary vector extensions (this is likely because you're using SwiftPM + the simulator, and is due to limitations with SwiftPM. This does not apply to real devices.).
This message will only be printed the first time this happens.
To suppress this message entirely, for all reasons, use `ZippyJSONDecoder.zjd_suppressWarnings = true
Wondering if it's a known & perhaps temporary issue, or some kind of limitation we have to accept and put up with.
Will it ever be possible to get benefits of this lib building/running on simulator?
Thanks in advance!
Trying to decode an array of objects throws an error claiming the file isn't valid JSON. The file was created by the Apple JSON Coder, which can also decode it just fine.
[{"hi":1,"there":2,"comment":"comment"},{"hi":2,"there":4,"comment":"comment"},{"hi":3,"there":6,"comment":"comment"},{"hi":4,"there":8,"comment":"comment"},{"hi":5,"there":10,"comment":"comment"},{"hi":6,"there":12,"comment":"comment"},{"hi":7,"there":14,"comment":"comment"},{"hi":8,"there":16,"comment":"comment"},{"hi":9,"there":18,"comment":"comment"},{"hi":10,"there":20,"comment":"comment"}]
Fatal error: 'try!' expression unexpectedly raised an error: Swift.DecodingError.dataCorrupted(Swift.DecodingError.Context(codingPath: [], debugDescription: "The given data was not valid JSON. Error: Unexpected error, consider reporting this problem as you may have found a bug in simdjson", underlyingError: nil)): file /Users/marcel/programming/Examples/CodingTests/CodingTestsSwift/AppDelegate.swift, line 90
func readZippyCoder(data:Data) -> [TestClass] {
NSLog("Zippy Decoding")
let coder=ZippyJSONDecoder( )
let array=try! coder.decode([TestClass].self, from: data)
return array
}
func readJSONCoder(data:Data) -> [TestClass] {
NSLog("Swift Decoding")
let coder=JSONDecoder( )
let array=try! coder.decode([TestClass].self, from: data)
return array
}
Hey there! I was integrating ZippyJSON into one of my projects, and I noticed that errors aren't thrown at the right time. I made a sample project demonstrating the issue here: https://github.com/noahsark769/ZippyJsonProject
The issue is that when the __JSONDecoder
unboxes a value, it doesn't throw and always returns a default value, but then inspects JNTError
later to throw. This means that code like this doesn't work:
let string = "{\"key\": 123}"
struct Example: Codable {
let key: String
init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)
self.key = (try? container.decode(String.self, forKey: .key)) ?? ""
}
}
let decoder = ZippyJSONDecoder()
do {
let data = string.data(using: .utf8)!
let element = try decoder.decode(Example.self, from: data)
print(element)
} catch {
print(error)
}
This will catch the error and print:
typeMismatch(Any, Swift.DecodingError.Context(codingPath: [JSONKey(stringValue: "key", intValue: nil)], debugDescription: "Expected PKc value but found Number instead.", underlyingError: nil))
This is an issue for me since I'm parsing JSON where one of the keys can be either a string or a number, and I'm not sure that there's a way to implement this with ZippyJSON right now. (Note: Swift's JSONDecoder
handles this case correctly.)
I think the fix would be to throw an error directly from __JSONDeocder
: even though we'd have to check JNTError
in every call to unbox
, this would technically be more correct and solve the above issue (I think).
Let me know if you have any further thoughts @michaeleisel - I'm happy to submit a pull request at some point soon!
Hi,
on MacOS (12.2.1, m1), i have this warning when using ZippyJSON:
SourcePackages/checkouts/ZippyJSONCFamily/Sources/ZippyJSONCFamily/JSONSerialization.mm: runtime: Undefined Behavior: Load of misaligned address 0x0001100566dd for type 'const uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment
after some digging, i found that it seems to be an issue in simdjson and was fixed by this pr:
simdjson/simdjson#1037
Simdjson 0.7 has now been released. Time to update the library?
This crash started happening in version 1.1, but did not happen for 1.0 or 1.0.1. I decode an array into two different types depending on which one matches the value.
Crash at ***
ZippyJSONDecoder:
if isKnownUniquelyReferenced(&wrapper.decoder) {
let innerDecoder = wrapper.decoder
*** JNTReleaseValue(innerDecoder.value)
(innerDecoder.value, innerDecoder.isEmpty) = try JSONKeyedDecoder<Key>.setupValue(value, decoder: decoder, convertToCamel: convertToCamel)
return KeyedDecodingContainer(wrapper.decoder)
}
JSONSerialization.mm:
void JNTReleaseValue(DecoderPointer decoder) {
*** delete decoder;
}
JSON:
"option": [
"24\" x 84\" (2x7)",
"36\" x 120\" (3x10)",
"36\" x 60\" (3x5)",
{
"option": "Other (Please Specify)",
"value": "bannerSizeOther"
}
],
in my code: single value decoding to either FormDriver or String:
edited to remove proprietary code
in my code: FormDriver/String array decoding
edited to remove proprietary code
The C++ is pretty fast and the performance characteristics are well understood. The Swift layer, however, is a big question mark. For example, moving from struct
to final class
was a big help. I have no further ideas, so this is an open call for anyone to look at ZippyJSONDecoder.swift and see what they can find. For example, I think we could do less retains and releases.
Hi 👋
This isn't necessarily an issue but a small suggestion.
I highly recommend that the README.md is updated to mention how much this framework benefits from Release optimisations.
In my personal case, I was looking into adding it to a personal app and after the initial results I was quite disappointed as ZippyJSONDecoder
was actually taking almost 100% more time than JSONDecoder
. It was only, after I stumbled in a few issues that I saw it was recommended to test it in a Release build, and, after building for Release instead of Debug, I actually saw the power of ZippyJSONDecoder
by decreasing the time it took to boot my app from 1.5s to 0.84s.
Very interested in trying out your library in my iOS app. Trying to add ZippyJSON as a Swift package dependency, it gives me the following error in Xcode 11.
Showing All Messages
: the package zippyjson[https://github.com/michaeleisel/ZippyJSON.git] @ 1.0.0 contains incompatible dependencies:
zippyjsoncfamily[../ZippyJSONCFamily] @ local
jjliso8601dateformatter[../JJLISO8601DateFormatter] @ local
I also tried first adding the two other dependencies separately, but it still fails. Any ideas what could be causing this?
Hi!
Currently, ZippyJSON cannot be added to iOS projects where the deployment target is less than 11.0 – the version that's specified in the Podspecs of ZippyJSON, ZippyJSONCFamily and JJLISO8601DateFormatter alike. (Even though the latter's README says it should be iOS 10+.)
But at the same time, there are availability checks that look for iOS 10.0, mostly around the ISO8601 date strategy, that are handled gracefully... (Which isn't necessary if the target is 11.0 anyway.)
Do you think it's possible to lower the deployment target to 10 or below?
Are you aware of any issues that would block such a move?
I'd really like to try using it in a more legacy-ish project :)
Thanks for this very promising library, by the way.
The following snippet reproduces the issue.
struct Model: Codable {
let amount: Decimal
}
let json = """
{
"amount": 12.34
}
"""
let jsonDecoder = ZippyJSONDecoder()
do {
let model = try jsonDecoder.decode(Model.self, from: json.data(using: .utf8)!)
}
catch {
print(error)
}
Results:
dataCorrupted(Swift.DecodingError.Context(codingPath: [LazyJSONKey(stringValue: "amount", intValue: nil)], debugDescription: "Invalid Decimal", underlyingError: nil))
iOS Version: 15.4.1
iOS Device: iPhone 13 Pro Max
It's strange, but I can't find ZippyJSON at Cocoapods.org anymore and the latest release (1.0.1) isn't available with this platform. Am I missing something?
Although I haven't had any reports of ZippyJSON causing a significant impact on app size, there's probably some low-hanging fruit lying around size that I could improve. There are two sorts of size contributions: that of the library itself, and (maybe?) from each individual invocation and inlining that could occur for it.
Right now, custom key decoding strategies cause ZippyJSON to fall back to apple's decoder, meaning there's no perf win. This issue is to gauge how often people need custom key decoding, why they need it, etc. to see if it should be supported, and if so, how.
So please let me know: do you use custom key decoding? What do you need it for, and why?
Right now, it only works with iOS and MacOS. Some things will need to be reworked for Linux (it basically can't use Objective-C)
I'm getting these Xcode warnings in my log after building.
ld: warning: direct access in function 'simdjson::haswell::implementation::stage2(unsigned char const*, unsigned long, simdjson::dom::parser&) const' from file '/Build/Products/Debug-iphonesimulator/ZippyJSONCFamily.o' to global weak symbol 'typeinfo name for std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >' from file '/Build/Products/Debug-iphonesimulator/ZippyJSONCFamily.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'simdjson::haswell::implementation::stage2(unsigned char const*, unsigned long, simdjson::dom::parser&) const' from file '/Build/Products/Debug-iphonesimulator/ZippyJSONCFamily.o' to global weak symbol 'typeinfo name for std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >' from file '/Build/Products/Debug-iphonesimulator/ZippyJSONCFamily.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'simdjson::haswell::implementation::stage2(unsigned char const*, unsigned long, simdjson::dom::parser&, unsigned long&) const' from file '/Build/Products/Debug-iphonesimulator/ZippyJSONCFamily.o' to global weak symbol 'typeinfo name for std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >' from file '/Build/Products/Debug-iphonesimulator/ZippyJSONCFamily.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'simdjson::haswell::implementation::stage2(unsigned char const*, unsigned long, simdjson::dom::parser&, unsigned long&) const' from file '/Build/Products/Debug-iphonesimulator/ZippyJSONCFamily.o' to global weak symbol 'typeinfo name for std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >' from file '/Build/Products/Debug-iphonesimulator/ZippyJSONCFamily.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
I get the following errors when trying to update Carthage with ZippyJSON in my Cartfile for a macOS project:
*** Skipped building ZippyJSONCFamily due to the error:
Dependency "ZippyJSONCFamily" has no shared framework schemes for any of the platforms: Mac
*** Skipped building ZippyJSON due to the error:
Dependency "ZippyJSON" has no shared framework schemes for any of the platforms: Mac
This issue is to track a case that was reported where ZippyJSON is only 7% faster than JSONDecoder
On macOS, for a CLI utility, Running this on a large (30gb) JSON file and getting the following error:
Swift/Integers.swift:3444: Fatal error: Not enough bits to represent the passed value
Works fine with small test file of same struct (json sample and model below)
Main difference when using Big file vs test file is it gets loaded into virtual memory, JSONDecoder() doesn't seem to have an issue with the big file, however it uses absurd amounts of memory/disk space for the ginormous file, and is very slow, hence the desire to use ZippyJSON.
Also note: This is how the data comes to me, I can't just split it out... The purpose of this utility is just that ;) trying to split it out.
struct Report: Codable {
let sensorAndUsageData: [SensorAndUsageDatum]
enum CodingKeys: String, CodingKey {
case sensorAndUsageData = "SensorAndUsageData"
}
}
struct SensorAndUsageDatum: Codable {
let accelerometer, gyroscope: [MotionSensorData]?
var motionSensorData: [MotionSensorData] { accelerometer ?? (gyroscope ?? []) }
enum CodingKeys: String, CodingKey {
case accelerometer = "com.apple.SensorKit.motion.accelerometer"
case gyroscope = "com.apple.SensorKit.motion.gyroscope"
}
}
struct MotionSensorData: Codable {
let metadata: Metadata
let sample: [Sample]
}
struct Metadata: Codable {
let device: Device
let timestamp: Double
}
struct Device: Codable {
let model: String
}
struct Sample: Codable {
let acceleration: Motion?
let start: Double
let rotationRate: Motion?
var motion: Motion { return acceleration ?? (rotationRate ?? Motion(x: 0, y: 0, z: 0))}
}
struct Motion: Codable {
let x, y, z: Double
}
{"SensorAndUsageData": [{"accelerometer": [{"metadata":{
"device" : {
"model" : "iPhone"
},
"timestamp" : 27342999.47155517
},"sample":[{"acceleration": {"x": -0.857421875, "y": -0.50927734375, "z": 0.01171875}, "start": 654428838.25630069, "timestamp": 194207.30908599999, "identifier": 0},
{"acceleration": {"x": -0.8583984375, "y": -0.50927734375, "z": 0.01220703125}, "start": 654428838.26624668, "timestamp": 194207.319032, "identifier": 0},
{"acceleration": {"x": -0.85791015625, "y": -0.509521484375, "z": 0.011962890625}, "start": 654428838.27619267, "timestamp": 194207.32897800001, "identifier": 0},
{"acceleration": {"x": -0.8583984375, "y": -0.509033203125, "z": 0.01220703125}, "start": 654428838.2861377, "timestamp": 194207.338923, "identifier": 0}]}]},
{"gyroscope": [{"metadata":{
"device" : {
"model" : "iPhone"
},
"timestamp" : 27342999.47155517
},"sample":[{"rotationRate": {"x": -0.857421875, "y": -0.50927734375, "z": 0.01171875}, "start": 654428838.25630069, "timestamp": 194207.30908599999, "identifier": 0},
{"rotationRate": {"x": -0.8583984375, "y": -0.50927734375, "z": 0.01220703125}, "start": 654428838.26624668, "timestamp": 194207.319032, "identifier": 0},
{"rotationRate": {"x": -0.85791015625, "y": -0.509521484375, "z": 0.011962890625}, "start": 654428838.27619267, "timestamp": 194207.32897800001, "identifier": 0},
{"rotationRate": {"x": -0.8583984375, "y": -0.509033203125, "z": 0.01220703125}, "start": 654428838.2861377, "timestamp": 194207.338923, "identifier": 0}]}]}]}
Using the v1.2.1 with SwiftPM on Xcode v13.1, I got this console log msg:
[ZippyJSONDecoder] Warning: fell back to using Apple's JSONDecoder. Reason: This library was not compiled with the necessary vector extensions (this is likely because you're using SwiftPM + the simulator, and is due to limitations with SwiftPM. This does not apply to real devices.). This message will only be printed the first time this happens. To suppress this message entirely, for all reasons, use `ZippyJSONDecoder.zjd_suppressWarnings = true
I'm seeing the following build failure when attempting to build ZippyJSON version 1.2.9 using Xcode 14.1 and Xcode 14.2 RC1:
/Users/tonyarnold/Developer/Repositories/ZippyJSON/Sources/ZippyJSON/ZippyJSONDecoder.swift:228:20: error: cannot find type 'JNTErrorInfo' in scope
var errorInfo: JNTErrorInfo = JNTErrorInfo()
^~~~~~~~~~~~
/Users/tonyarnold/Developer/Repositories/ZippyJSON/Sources/ZippyJSON/ZippyJSONDecoder.swift:229:5: error: cannot find 'JNTGetErrorInfo' in scope
JNTGetErrorInfo(context, &errorInfo)
^~~~~~~~~~~~~~~
x-posting this issue here (sorry, I didn't realize that michaeleisel/ZippyJSONCFamily
wasn't actively watched!)
See also: michaeleisel/ZippyJSONCFamily@c55123b
From xcodebuild
when pointing at SPM package michaeleisel/[email protected]
:
Not sure if a commit didn't get pushed, while the tag did!
iPhone XS
13.3.1
struct User: Decodable {
let firstName: String
let lastName: String
let email: String
let login: String
let passwordHash: String
let gender: String
let avatarUrl: String
let country: String
let city: String
let zipCode: Int
let phone: String
let isVip: Bool
let isFamous: Bool
}
JSONDecoder
is 20-35% faster than ZippyJSONDecoder
Hi, thanks for a great work!
Faced a problem while using ZippyJSON '~> 1.2.5' which requires JJLISO8601DateFormatter version 0.1.4. But current JJLISO8601DateFormatter podspec has 0.1.3 version whereas the last JJLISO8601DateFormatter release is only 0.1.2
I know that pretty much folks not using Decodable protocol because in case of model properties names in Swift and JSON responses are different, you'll have to write large CodingKey enums.
To avoid this, to add more flexibility to framework users, I think it would be cool to add JSON deserialization implementation with NSJSONSerialization class.
What do you think?
Thanks you in advance
It seems that this project only supports Swift 5.1 and not Swift 5? I am unable to compile on Swift 5 due to missing returns as well as a No template named 'deque' in namespace 'std'
.
Firstly, Thank you for your attempt in area of JSON parsing smooth & faster by adapting robust functionality of C & C++.
I am using Swift 5.0 as Primary programming language for my iOS application.
I am not sure, How would I make use of this library.
However, I have integrated this library into my demo project using Cocoapods.
But, don't exactly know How would I make use of this library.
It would be fruitful to have little demo app that showcase the utilisation of this library.
Thank you.
Rashesh
This library is breaking SwiftUI Previews.
Error:
/x.swift:9:8: Could not find module 'ZippyJSON' for target 'arm64-apple-ios-simulator'; found: x86_64-apple-ios-simulator, at: /Users/x/Library/Developer/Xcode/DerivedData/CricHQ-dmjqadgxdcinrrcgwugqdedztquy/Build/Products/Debug-iphonesimulator/ZippyJSON.swiftmodule
In https://github.com/michaeleisel/ZippyJSONCFamily/blob/c7fa94c7983fa9becc4f8af0e42560d9fc80571f/Sources/ZippyJSONCFamily/simdjson.cpp#L32 you're missing case 14: UNCLOSED_STRING
, so when ZippyJSON tries to get the error msg it crashes.
The test case I was seeing it with is:
{
"key: "yes"
}
Note the missing "
You also have a typo for UNESCAPED_CHARS
, 'escapted' instead of 'escaped' twice.
I replace JSONDecoder with ZippyJSONDecoder in Lottie library but it stops decode correctly. I get error:
typeMismatch(Swift.Array<Any>, Swift.DecodingError.Context(codingPath: [JSONKey(stringValue: "v", intValue: nil)], debugDescription: "Tried to unbox array, but it wasn\'t an array", underlyingError: nil))
I tried to parse this file: Lottie file
There are 2 cases where "v" is a key:
Hi, i've got an archiving error on ZippyJSON when archiving my app project, in the simdjson.cpp file :
really_inline value128 full_multiplication(uint64_t value1, uint64_t value2) {
value128 answer;
#ifdef _MSC_VER
// todo: this might fail under visual studio for ARM
answer.low = _umul128(value1, value2, &answer.high);
#else
__uint128_t r = ((__uint128_t)value1) * value2;
answer.low = r;
answer.high = r >> 64;
#endif
return answer;
}
I have no idea what changed between xcode versions but i had to rollback to using the UIKit regular JSONDecoder.
Highlights
New features:
Performance:
System support:
When trying to decode a Codable primitive value at root level, these errors are thrown:
Error thrown by ZippyJSONDecoder: "The data couldn’t be read because it isn’t in the correct format."
Error thrown by JNT: "The given data was not valid JSON. Error: Problem while parsing a string"
As of iOS 13.1+ and macOS 10.15.1+, JSONDecoder is capable of decoding Codable primitive values, so my tests for encoding/decoding primitive values pass with the standard JSONDecoder, but fail with ZippyJSONDecoder.
func testExample() {
enum ExampleEnum: String, Codable {
case value
}
let codablePrimitive: ExampleEnum = .value
do {
let data = try JSONEncoder().encode(codablePrimitive)
let decoded = try JSONDecoder().decode(ExampleEnum.self, from: data)
let zippyDecoded = try ZippyJSONDecoder().decode(ExampleEnum.self, from: data)
XCTAssertEqual(decoded, codablePrimitive)
XCTAssertEqual(zippyDecoded, codablePrimitive)
}
catch {
XCTFail(error.localizedDescription)
}
}
The Failure seems to be down to just the Package.swift
file getting an old verson from tag 1.2.1
the File looks like this in the tag:
// swift-tools-version:5.1
import PackageDescription
let package = Package(
name: "ZippyJSON",
platforms: [
.iOS(.v11),
],
// snip
This will fail building with:
JSONDecoder.swift:20:32: ‘withInternetDateTime’ is only available in macOS 10.12 or newer
Using the master
branch in with Swift package gets the correct Package.swift
file and builds successfully 🎉
Please tag and release the current files in the repository as a version so we do not have to use master
in Swift Packages.
Thanks!
This is because here:
JNTCreateContext is called with empty strings when nonConformingFloatDecodingStrategy == .throw""
is then interpreted here:
My guess is that there's the stringForFloats
variable that is intended to be passed on to simdjson:
ZippyJSON/Sources/ZippyJSON/ZippyJSONDecoder.swift
Lines 344 to 349 in c380ac9
For a json file, if we only run once of decoding, it seems no improvement of CPU time cost when comparing with JSONDeocoder.
My app have more than 100 json files, and each file is a unique Model. Total time cost with JSONDeocder is about 2.0 seconds, and with ZippyJSONDecoder is about 2.5 seconds, so Zippy performs even worse.
I did some tests with ZippyJSON's test cases, and find same result.
Example:
Modify file Tests/Models/github_events.swift, replace all Date virables to String, such as changer let createdAt: Date to let createdAt: String , in order to ignore the affect of Date decoding, as README said:
date parsing for ISO-8601 dates is 10x faster due to using JJLISO8601DateFormatter instead of Apple's date formatter.
then run run("github_events", ghEvents.self, dateDecodingStrategy: .iso8601)
And print all 10 times data , no only focus on the final average time.
// ZippyJSONDecoder
[0.0027, 0.0012, 0.0012, 0.0012, 0.0012, 0.0011, 0.0008, 0.0008, 0.0008, 0.0008]
// JSONDecoder
[0.0031, 0.0025, 0.0025, 0.0025, 0.0025, 0.0025, 0.0022, 0.0020, 0.0020, 0.0020]
So, if we only compare the first time, 0.0027 vs 0.0031, seems no 3x faster.
And I find below logic in ZippyJSONDecoderTests.swift
func averageTime(_ closure: () -> ()) -> CFTimeInterval {
let count = 10
var times: [CFTimeInterval] = []
for _ in 0..<count {
times.append(time(closure))
}
return times.dropFirst(count / 3).reduce(0, +) / CFTimeInterval(times.count)
}
As code shows, when calculating average time, we dropped first 3 cases, exactly cases that perform not so good.
Why we need to drop first 3 cases?
And why the first time has no 3x improvement? any way to optimize this?
Best wishes~
Right now, it uses strtod
, which is fairly slow. We can do better, let's see what the result of simdjson/simdjson#242 is.
My app represents JSON in tree view(NSOutlineView). So, apparently my app does not have any concrete types hence I cannot use JSONDecoder
Can I use ZippyJSON for functionality which would be similar to NSJSONSerialization
which would get me a native Swift dictionary representation?
Hi,
I need to parse remote date encoded as iso8601 with fractional seconds. However, using something like:
let decoder = ZippyJSONDecoder()
decoder.dateDecodingStrategy = .formatted(ISO8601withFractionalSeconds())
Seems to be as slow as classic JSON, so I guess it fallbacks to default when using formatted
as well as custom
? How can I proceed?
Thanks!
Any chance you could add SPM support? Now that SPM is build into Xcode it will probably grow into the most used package manager for Swift projects so it would be great to support it.
I am currently working on a side project where I need to parse multiple GB of json data and I would love to use this library but the project uses SPM as a dependency manager.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.