2

In Cocoa, is NSThread faster than pthread? is are any performance gain? is it negligible to ignore?

ReachConnection
  • 1,831
  • 6
  • 22
  • 32

4 Answers4

10

I have no data to back this up, but I'm going to go out on a limb and say "they're equivalent". NSThread is almost certainly wrapper around pthread (is there really any other way to create a system thread?), so any overhead of using NSThread versus pthread would be that associated with creating a new object and then destroying it. Once the thread itself starts, it should be pretty much identical in terms of performance.

I think the real question here is: "Why do you need to know?" Have you come up against some situation where spawning NSThreads seems to be detrimental to your performance? (I could see this being an issue if you're spawning hundreds of threads, but in that case, the hundreds of threads are most likely your problem, and not the NSThread objects)

Unless you have proof that the creation of an NSThread object is a bottleneck in your application, I would definitely go with the "negligible to ignore" option.

Dave DeLong
  • 242,470
  • 58
  • 448
  • 498
  • in my application, spawning a separate NSThread decreases my function output. I asked this question because I thought NSThread priority might come into play where the system is not allocating enough resources to my spawn thread – ReachConnection Jan 14 '10 at 20:48
  • 1
    It's more likley they're both wrappers around the same underlying OS mechanism to create threads. Meaning, NSThread, being part of the OS provided SDK, has no reason to go through the pthreads API like a "normal" program would have to. But, I too, am only guessing. I agree they're equivalent, and if they weren't the NSThread people would work to make it so. – Terry Mahaffey Jan 14 '10 at 20:49
  • @Terry it's possible. GNUStep, at least, is using pthread: http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/Source/NSThread.m – Dave DeLong Jan 14 '10 at 20:55
  • 3
    There is effectively no difference between the two beyond a very slight amount of overhead upon instantiation. If instantiation overhead is measurable in your application, you are doing it wrong. Specifically, you shouldn't be spawning and killing threads rapidly -- very inefficient. – bbum Jan 14 '10 at 22:19
  • @Terry: I can't speak authoritatively about the current implementation, but NSThread has definitely been based on pthreads at least in the past. – Chuck Jan 15 '10 at 04:05
1

pthreads actually have slightly less overhead, but I can't imagine it will make any difference in practice. NSThread uses pthreads underneath. The actual execution speed of the code in your thread will be the same for both.

Chuck
  • 234,037
  • 30
  • 302
  • 389
0

I would also guess that any "overhead" or "instantiation difference" you pay as an extra for NSThread, would be evened by the extra cycles and calls you will eventually need to perform, to configure your pthread correctly, using pthread APIs.

I believe the NSThread is nothing but convenience wrapper that saves some coding in Cocoa/Cocoa-touch applications that want to be multithreaded.

Motti Shneor
  • 2,095
  • 1
  • 18
  • 24
0

Under iPhone SDK, NSThread uses pthread as an actual thread. Frankly, they're equivalent.

However, we can access "deep" settings via pthread APIs if we use pthread API. For example, scheduling way, stack size, detached or not, etc. These API are hidden by NSThread capsule.

Therefore, under some conditions, pthreads win.

KatokichiSoft
  • 932
  • 5
  • 8
  • Well, the point of abstraction is to hide implementation details. Frankly, the size of the stack, the thread priority, etc can all be considered "details". Usually when threading we are just going for concurrency. That being said, `NSThread` does have `-setThreadPriority:` and `setStackSize:`. – Dave DeLong Jan 15 '10 at 20:17