[swift-corelibs-dev] Rules on adding dependencies

[Tony Parker]

> On Dec 5, 2015, at 9:17 AM, Geordie Jay <geojay at gmail.com> wrote:
> 
> Sorry to spam, but I’ve just run some tests re: memory usage and found that running NSJSONSerialization.JSONObjectWithData() repeatedly results in huge memory usage (unbounded into the gigabytes). The pure Swift version I’ve been working on remains at a constant and minimal ~2 MB memory usage.
> 

I’d be interested in seeing your test case. I certainly didn’t intend for NSJSONSerialization to take gigabytes of memory. I wonder if it’s possible that an autorelease pool is simply never being popped when calling from Swift.

- Tony

> I’m not sure what the reason for this is huge discrepancy is. I assume the current Foundation version is using as much memory as it can for efficiency, but this may be another reason not to trust NSJSONSerialization is the best possible outcome, especially for embedded systems, servers, and the like. Considering the minimal CPU time difference, I would again vote for a pure Swift version, and focus on improving the standard library decoding speeds if possible.
> 
> 
> On Sat, Dec 5, 2015 at 5:58 PM, Geordie Jay <geojay at gmail.com <mailto:geojay at gmail.com>> wrote:
> 
> What I’m not so sure about is the most efficient way of working with NSData in this context, considering we are very much assuming the data to have come from a String of some kind (correct me if I’m wrong). So it seems to me like taking NSData insead of just a String is a regression into Objective-C land.
> 
> Can anyone explain why we might want to do this rather than working in an idiomatic Swift way (obviously backwards compatibility is a big one – is it the only one?). The only other thing I can think of is that NSData can be streamed. That is going into territory that I haven’t dealt with in Swift yet though. Would love to hear some input from others on this.
> 
> 
> On Sat, Dec 5, 2015 at 5:29 PM, Geordie Jay <geojay at gmail.com <mailto:geojay at gmail.com>> wrote:
> 
> I’m not sure about performance hit of calling C from Swift either (it should be statically linked, so I suspect there is none), but the performance is only marginally slower than NSJSONSerialization as is, in the pure Swift version I am making. My test character set is about 2000 characters long, running serialize on it 5000 times, my current Swift-only version takes 1 second for each test run, and the existing (C-backed) NSJSONSerialization takes about 0.75 seconds.
> 
> The difference isn’t huge and I suspect with more optimisation of the Swift code and of the standard library (in particular comparing UTF16 strings) this gap would disappear. I for one would be in favour of a pure Swift solution for readability, and also as a challenge to improve the standard library’s performance.
> 
> Another thing to note is that Swift is supposed to be future-proofed in terms of UTF String handling (I’m not sure about JSON though, to be honest – is it supposed to support CharSets beyond UTF8?), maybe having the strings decode in UTF16 by default is not such a bad idea, even if it has a minor performance hit for now.
> 
> 
> On Sat, Dec 5, 2015 at 5:17 PM, Tom Leavy <tom at wickr.com <mailto:tom at wickr.com>> wrote:
> 
> I would rather go right to the end game here and just work on coding up an implementation of JSON encoding / decoding and making it conform to the NSJSONSerialization spec. I can set up a repo for us to work on it. 
> 
> The main decision here, is do we code a small lib in C and then call it from the Swift side, or do we just write the entire implementation in Swift? From a performance standpoint C is usually my go to, but if we use swift with only structs and we really focus on minimizing use of functions that would be costly / do a lot of profiling and optimization we can get very close to equivalent performance? At least to the level of the current objective c / c version? I'm also not sure of potential performance penalties of calling C functions from swift. Someone with more knowledge will have to weigh in on that one. 
> 
> Thomas Leavy | Wickr Inc.
> VP Mobile Applications & Architecture | Newark, NJ <x-apple-data-detectors://0/1>
> 
> On Dec 4, 2015, at 6:24 PM, swizzlr <me at swizzlr.co <mailto:me at swizzlr.co>> wrote:
> 
>> Re: Rules on adding dependencies
> This e-mail message is intended only for the named recipient(s) above and is covered by the Electronic Communications Privacy Act 18 U.S.C. Section 2510-2521. This e-mail is confidential and may contain information that is privileged or exempt from disclosure under applicable law. If you have received this message in error please immediately notify the sender by return e-mail and delete this e-mail message from your computer, mobile devices and any cloud storage backup systems as well as destroy any printed copy you might have made. 
> 
> 
> 
>  _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151205/53575e3a/attachment.html>