• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Results of timing test.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Results of timing test.


  • Subject: Results of timing test.
  • From: John Draper <email@hidden>
  • Date: Thu, 13 Apr 2006 00:47:13 -0700

Performance results

This is the inherent delay from the time from just before I insert my code into
the main thread, until the beginning of 'processIncomingData'.


Time it takes to get from beginning of 'performSelectorOnMainThread'
to start of 'processIncomingData'

Test Number            Time in Microseconds
-----------         --------------------
1                    1744
2                    300
3                    432
4                    942

// This is code that is called from within a thread.
- (void)incomingPacket:(char *)theData
ofLength:(int)len
{
// Construct a data object from pointer and length
NSData *data = [NSData dataWithBytes:theData
length:len];
// Force following method to execute in main loop
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];


// Following two lines are to test time interval, I stamp start time here.
if (strt) {
RTPTime st = RTPTime::CurrentTime();
ms = st.GetMicroSeconds();
}
[self performSelectorOnMainThread:@selector(procFromMainLoop:) withObject:data waitUntilDone:NO];
[pool release];
}


// This is code that HAS to be run only from main event loop.
- (void)procFromMainLoop:(NSData *)myData
{
if (strt) {
RTPTime st = RTPTime::CurrentTime();
uint32_t ems = st.GetMicroSeconds();
ems = ems - ms;
strt = false; <--- I put breakpoint here....
}
[mAudioTransporter processIncomingData:myData];
}
These are defined globally... for this test only.


uint32_t ms;
bool strt = true;

So, I'm loosing a millisecond... That is tolerable, although not totally desirable. I would rather not
have to wait before my code is inserted into the main event loop. I'm sure there are going to be
situations where there are worse delays then this.


So, I have a question... Where in the event loop will my code get inserted? At the beginning, or the
end? I don't suppose it matters actually, oh well....


So I confirmed that "processIncomingData" cannot be called from within a thread. And by calling it
shortly after that in the main loop has eliminated my problem.


Ok,  so I have another question...   could I do this...

 NSLock *theLock = [[NSLock alloc] init];

 if ([theLock tryLock]) {
        [mAudioTransporter processIncomingData:myData];
        [theLock unlock];
 }

Or,  I could do this......

   id condLock = [[NSConditionLock alloc] initWithCondition:NO_DATA];
   [condLock lock];
   [mAudioTransporter processIncomingData:myData];
   [condLock unlockWithCondition:HAS_DATA];

Any comments please?

John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: I think I weaseled out or my thread problem.
  • Next by Date: Is there any difference in speech recognition APIs in mac mini & macbook pro
  • Previous by thread: I think I weaseled out or my thread problem.
  • Next by thread: Is there any difference in speech recognition APIs in mac mini & macbook pro
  • Index(es):
    • Date
    • Thread