Hey there, I'm using your library, although with a few modifications. I'm using it to parse 50mb json files with which the apple json parsing fails.
It would be great if you used "JString" instead of String across Freddy.
(where JString is a typealias to String).
And have an internal JString construction function (extension or non class function) which takes an [Int8] (or if you've changed the parsing from my last download, whatever you use as a string collector.
I have implemented this on my end, and it allows me to use a custom String class instead of Swift.String. Swift.String is very, very slow. Very, very, very slow.
Also- it would be great if, actually, an Unsafe pointer to Int8 was used instead of [Int8], because in (my side) 99% of cases, we don't need to build this array, but can use memory straight from the original buffer. (Faster). And then if you are using a custom JString, it is possible to not actually copy that memory at all if one ensures the original buffer is not destroyed.
(I have not implemented the latter, will probably do in the summer).
We don't intend to make any changes here. On our side, Freddy is in maintenance mode and only considering bug fixes at this time. Please file your performance concerns with Swift JIRA.
Hey there, I'm using your library, although with a few modifications. I'm using it to parse 50mb json files with which the apple json parsing fails.
It would be great if you used "JString" instead of String across Freddy. (where JString is a typealias to String).
And have an internal JString construction function (extension or non class function) which takes an [Int8] (or if you've changed the parsing from my last download, whatever you use as a string collector.
I have implemented this on my end, and it allows me to use a custom String class instead of Swift.String. Swift.String is very, very slow. Very, very, very slow.
Also- it would be great if, actually, an Unsafe pointer to Int8 was used instead of [Int8], because in (my side) 99% of cases, we don't need to build this array, but can use memory straight from the original buffer. (Faster). And then if you are using a custom JString, it is possible to not actually copy that memory at all if one ensures the original buffer is not destroyed.
(I have not implemented the latter, will probably do in the summer).
Thanks for a great library.