Thanks again. I have given numbers in my original message. Messages are limited in size 1000 bytes. I have up to 3 instances of my bidirectional socket. - Audio Video and some variant of screen-sharing (similar in behavior to Video). Audio socket can receive up to 100 messages a second - each message exactly 84 bytes. Video (and the third) will regularly receive ~30 messages a second, each message up to 1000 bytes, but can momentarily rise to 100 messages a second.
This means I can roughly expect to call read:maxLength: about 60 - 200 times a second If I’m to abandon my ring buffer. The other side - allocating and copying incoming messages off my ring-buffer, is also a little extensive. Parsing the messages is very fast and negligible (merely cast a C-struct over the message pointer). I then perform some complicated logic over the parsed messages - but this logic cannot change whatever socket implementation I choose. Then I need to serially pass these messages serially (not concurrently) to an external media engine, that will - again - copy them into its own queues, and will process them in its internal threads. From experiments and using instruments, I learned it’s not very fast with taking in my messages. This is not a high-performance situation - but my socket supports iOS and Mac, with devices ranging from iPhone4 and iPad2 up to the latest Mac computers. On iPhone-4 we suffer performance issues today, and the socket implementation is responsible for at least some of it. > On Sep 17, 2015, at 18:58, Jens Alfke <j...@mooseyard.com> wrote: > > >> On Sep 17, 2015, at 2:24 AM, Motti Shneor <su...@bezeqint.net >> <mailto:su...@bezeqint.net>> wrote: >> >> Is there a specific penalty to NSStream’s method read:maxLength: ? If I call >> it on the average 2-3 times a message, Is this far worse than reading big >> bulks off the stream, then doing all my book-keeping and copying and locking? > > It depends on how often you’re calling it, and the relative cost of reading > vs parsing vs handling messages. In most use cases the kernel call overhead > isn’t very significant. IIRC, you haven’t given us any specific numbers, or > any indication that this is a super-high-performance situation. > >> Last, several guys mentioned GCDAsyncSocket. What is it? an open-source >> thing? a system API I’m not aware of? > > > http://lmgtfy.com/?q=GCDAsyncSocket <http://lmgtfy.com/?q=GCDAsyncSocket> ;-) > Or alternatively, right-click on ‘GCDAsyncSocket’ and choose “Search With > Google” from the context menu. > I’m not trying to be snarky, just pointing out that these days asking “what > is X” is usually slower than looking it up yourself. > > —Jens Motti Shneor, CEO, suMac LTD. Software Development for the Macintosh Home/Office Address: 34 Emek-Ha-Ella St. Appt.1 Modiin, ISRAEL, 71723 Home/Office Tel/Fax: +972-8-9267730 Home eMail: motti.shn...@gmail.com Office eMail: su...@bezeqint.net Mobile phone: +972-54-3136621 --- ceterum censeo microsoftiem delendam esse ---
_______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to arch...@mail-archive.com
