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._______________________________________________ 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
