Le 18 juil. 2010 à 11:17, Ryan McGann a écrit : > > On Jul 18, 2010, at 7:42 AM, Rafael Cerioli wrote: > >> Le 18 juil. 2010 à 03:03, Ryan McGann a écrit : >>> Unfortunately, I can't find the sources at the moment as it was a while >>> ago, but there was an interesting discussion about this topic on the >>> macnetworkprog mailing list. Apple found in the early days of iPhone >>> programming that threads are (in general), a bad idea for networking, and >>> it was made worse by the fact that the iPhone has only 1 CPU. Apple's >>> resident kernel networking engineers (the guys that would know about >>> networking latency the most), as well as the venerable Quinn "the Eskimo" >>> from Apple DTS, basically boiled it down to this: >>> Rule #1. Networking code is dominated by network latency, not CPU >>> cycles. >>> Rule #2. Don't use threads for networking without thoroughly profiling >>> your application. >>> >>> Downloading a file, even if it can be done in a single TCP packet (after >>> the RTT of the handshake) can take 20-30 milliseconds easily, and that's if >>> the server responds instantaneously and no DNS lookup is involved. Your >>> application only gets 10 milliseconds of CPU time anyway so it'll sleep >>> several times before the file is received, and that's if a bunch of other >>> things are true first. >>> >>> Your application, if well behaved will never notice network latency. On the >>> iOS devices, setting up a thread (creating the thread context, scheduling >>> it in the kernel and context switching to the new thread) can take a full >>> thread quantum. GCD helps but only so much. >>> >>> Now, when SSL gets involved things are murkier. The certificate exchange >>> can take 100's of milliseconds and is moderately CPU intensive (compared to >>> the network data transfer which is relatively insignificant). It still all >>> happens in the background (when using NSStream) and your application should >>> get ample CPU time, but if you have several connections at once you could >>> find your app getting slowed down. >>> >>> If, and only if, you find your application is being blocked by threading >>> (usually the result of SSL negotiation) then you should think about >>> threading your networking. Otherwise, trust the threading model of the >>> higher level networking APIs. >>> >> >> >> Thank you for that! It's seems very accurate! >> >> So, correct me if I'm wrong (I just want to be sure that I got it), you are >> saying that if in put my networking code into a thread, then I will lost one >> cpu cycle for the thread creation and scheduling, then several other cycles >> for nothing to wait until the packet is downloaded (an so on for each packet >> transmission). >> Would it mean that my app will be less responsive because switching between >> threads for nothing (is this a performance cost?), or just that my download >> will take more time ? > Anytime you use a thread, you will lose some CPU cycles in creating the > thread & waiting for the OS to switch to the new thread to execute. iOS 4 has > Grand Central Dispatch which can reduce the cost of this, but on single > core/CPU devices, there's still a big cost for something that isn't strictly > necessary. The thread will just sit there waiting for packets to arrive, and > threads are best used when you know that the thread will be busy most of the > time. > > If the OS is busy switching back and forth between your main thread and the > networking thread, that's CPU cycles spent in context switching instead of > inside your application. The download will take slightly longer (microseconds > probably) due to this overhead, but more importantly the CPU will be working > harder unnecessarily. > >> Another aspect : would the memory required to run another thread have a >> significant impact on my app memory footprint ? (I guess it all depends on >> the number of threads?) > Each thread requires a a certain amount of memory, so yes using another > thread will consume more memory on the device. Each thread also consumes > kernel resources that are wired down, which is even worse. > > Not to say all threads are bad. But they don't always make sense, especially > in networking.
Thank you, crystal clear now! Regards, Rafael_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
