4

In profiling an iOS game on an iPhone 3G, instruments is reporting that the system call pthread_setspecific (which is being called from many seemingly unrelated locations) is the biggest CPU bottleneck. Google tells me this deals with storing meta data for threads, however I'm not sure how to track this down since the entire engine is a single thread. Does this have to do with CADisplayLink? Can I optimize specific scenarios to better account for this?

Here's some relevant information that may be helpful in answering my questions:

  • Device: iPhone 3G
  • iOS version: 4.2.1
  • Game-code is entirely C++, with application layer in obj-C.
  • The game uses OpenglES1.1
  • Unfortunately both RTTI and C++ exceptions are both required and thus enabled.
  • This is running a release build (with debug symbols) through the CoreAnimation profiler in instruments.
grahamp
  • 127
  • 7
  • In terms of "self time" it may well be using the most. What you need to know is which routines are calling it, and which are calling _those_, and so on. Any program that basically just calls system functions will look like that. – Mike Dunlavey Aug 04 '11 at 01:33
  • @Mike Nothing directly calls it, however if I look at the profiling information, it's being called from many many seemingly random places (like singleton instance methods). It's either something gcc/iOS adds to function calls, or it's something to do with switching thread contexts? Sorry I'm not very familiar with threading. :/ – grahamp Aug 04 '11 at 03:07
  • Yeah, that's the kind of nonsense some profilers give you. That's why [I use this method](http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c-code-in-linux/378024#378024). If it's spending enough time in that routine to care about, you'll catch it in there, and then you'll see exactly why it's being called. – Mike Dunlavey Aug 04 '11 at 13:32
  • pthread_setspecific is probably used to implement thread local variables. Are you using thread local variables? Singletons that are actually thread specific singletons could cause this. – Joseph Garvin Sep 19 '11 at 21:26

1 Answers1

2

Code generated by exception handling is using thread local storage to store its unwinding stack. There is nothing you can easily do. Try to remove exception when possible. Compile part of the code without it.

crazyjul
  • 2,519
  • 19
  • 26