Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delegate methods to avoid copying NSData messages #424

Closed
erikprice opened this issue Jun 24, 2016 · 3 comments
Closed

Delegate methods to avoid copying NSData messages #424

erikprice opened this issue Jun 24, 2016 · 3 comments

Comments

@erikprice
Copy link
Contributor

erikprice commented Jun 24, 2016

I have a PR that I would like to submit, which adds SRWebSocketDelegate methods to allow the delegate to choose whether to copy the NSData messages received over the web socket:

/**
 Called to determine whether to copy outbound data before sending.

 Default (if not implemented) is to copy.

 @param webSocket An instance of `SRWebSocket` that is about to send a message.
 @param data      Data to send in a form of `NSData`.
*/
- (BOOL)webSocket:(SRWebSocket *)webSocket shouldCopyDataToSend:(id)data;

/**
 Called to determine whether to copy inbound data before sending to `-webSocket:didReceiveMessage:`.

 Default (if not implemented) is to copy.

 @param webSocket An instance of `SRWebSocket` that received a message.
 @param data      Received data in a form of `NSData`.
*/
- (BOOL)webSocket:(SRWebSocket *)webSocket shouldCopyReceivedData:(NSData *)data;

We have been using a customized version of SocketRocket based on 0.5.0 that uses these methods to disable the copying of the web socket messages, which has brought us noticeable performance gains. I wanted to submit our changes back as a PR, but the SRDelegateController API has been added in more recent versions of the library. This calls delegate methods asynchronously, so there doesn't seem to be a preferred way to have delegate methods that return values. So I have two questions:

  1. Would the SocketRocket library welcome a PR to bring this functionality? We would prefer not to continue to maintain a custom-patched version of the library in order to have it. Notice that it would be opt-in, and the default behavior would be to remain the same (copy NSData objects).
  2. If the answer to 1 is yes, do you have any recommendations on how the delegate object could communicate the policy to the SRWebSocket object?
@nlutsenko
Copy link
Contributor

Both of these are a very good addition, but I think we can do better than this, specifically for shouldCopyDataToSend::
Add a method sendDataNoCopy:error: in addition to existing one, which will directly relate to how you want the data to be sent.

I am curious on the internal impact of the receiving end as well, since we try our best to never copy anything unless we have to, meaning that if you have an optimization for these - we should merge it without even asking whether someone wants to have a copy of received data or not.

@erikprice
Copy link
Contributor Author

I am curious on the internal impact of the receiving end as well, since we try our best to never copy anything unless we have to, meaning that if you have an optimization for these - we should merge it without even asking whether someone wants to have a copy of received data or not.

We have been using our patched version of SocketRocket 0.5.0 for quite some time, and we do implement the delegate method to skip making a defensive copy of the NSData received over the web socket. While I'm sure the original maintainers had good reason for making the copy, skipping it has not caused us any problems, and has resulted in noticeably better performance for us.

Do you want me to submit a PR that simply removes the call to -copy instead of adding a delegate method and making this optional?

@erikprice
Copy link
Contributor Author

Closing, as this has continued in #427 and #428.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants