[swift-server-dev] [swift-dev] Performance Refinement of Data

[Helge Heß]

On 29 Nov 2016, at 16:36, Alex Blewitt <alblue at apple.com> wrote:
>> Hm, I don’t know. Something I don’t quite get is why this is even required. What is really different between that `Data` and a `[ UInt8 ]`? Just the bridging to NSData (which we don’t have on Linux), and couldn’t all that bridging stuff described be done against a special [UInt8] array-backend class too?
> 
> For one thing, a [UInt8] backed type has a fixed structure in memory (for example, it must be contiguous).

I thought that is the difference between Array and ContiguousArray? (Array not requiring a fixed structure in memory).

My thinking was that if an Array<ObjC> can be backed by an NSArray, and Array<UInt8> could be backed by an NSData (or something similar) by the same ‘magic'. The thing missing would be access to physical ranges of a non-contiguous Array, but that is desirable for all types, not just bytes.

I don’t care too much, but I think people will find it kinda weird what the difference is between an array of bytes and an array of bytes :-) Would be kinda beautiful to make them the same.


> A Data type has an opaque storage type which could permit a linked list of blocks (for example). It's also possible to create a Data object which is based on a subset of an original Data without copying. There are also custom deallocator routines which do things differently based on what type the data came from (for example, unmap or free).

I’m not entirely sure what you are talking about. About the `Data` type described in the proposal you sent, or `NSData` (mapped to `Data` right now, the one the proposal is targeting to replace), or `DispatchData`?

The proposal doesn’t talk at all about the opaque storage aspects you are mentioning (linked Data etc) hence I was assuming it is just a buffer. It sounds like it is considered implicit that the new `Data` would preserve all the functionality of NSData?

Most of your replies relate to the `NSData backed Data`, I skip those as I was just referring to the proposal. Yes, the ‘old’ Data provides a lot of the facilities required.

BTW: While Data can iterate over sub buffers within a closure, I don’t think it can give you a list of pointers to them for writev() and companions?


> Of course the other reason is that Data exists across a number of existing APIs and that's unlikely to change. So making this more efficient will help those use cases.

That one is easy: `typealias Data = [UInt8]` ;-)


> I would expect that a high-performance JSON or XML parser that takes a Data would probably find it more efficient to iterate through the contents directly rather than going through a String representation first, though.

I agree, but eventually it’ll (or part of it) get converted to some String. The top-level users will get to see such, presumably.


> I think performance is definitely high up on the list of things that are required, but we should also look at the aspects of using the standard buffer type provided by the platform. If we have performance tests/metrics that show a performance delta to using a plan [UInt8] or equivalent then it would be good to test those or provide them as test cases for the core Swift team.

Yes, sorry. I was only looking at the proposal you sent which doesn’t mention any of the facilities you do nor includes performance stats for those (which are more important to the server than the one included). That the new `Data` would have all the facilities of NSData wasn’t obvious to me.

hh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161129/b5982c72/attachment.sig>