Oto moja odpowiedź na zegary zegarowe z wykorzystaniem zarówno mach_absolute_time()
, w oparciu o metodę obliczeń shown here, jak i NSDate
. W rzeczywistości są one takie same pod względem dokładności.
wersja Mach
double machGetClockS()
{
static bool init = 0 ;
static mach_timebase_info_data_t tbInfo ;
static double conversionFactor ;
if(!init)
{
init = 1 ;
// get the time base
mach_timebase_info(&tbInfo) ;
conversionFactor = tbInfo.numer/(1e9*tbInfo.denom) ; // ns->s
}
return mach_absolute_time() * conversionFactor ; // seconds
}
double machGetClockDiffS()
{
static double lastTime = 0;
double currentTime = machGetClockS() ;
double diff = currentTime - lastTime ;
lastTime = currentTime ; // update for next call
return diff ; // that's your answer
}
NSTimeInterval wersja
double getClockS()
{
return [NSDate timeIntervalSinceReferenceDate] ; // NSTimeInterval is always specified in seconds
}
double getClockDiffS()
{
static double lastTime = 0 ;
double currentTime = getClockS() ;
double diff = currentTime - lastTime ;
lastTime = currentTime ; // update for next call
return diff ; // that's your answer
}
Wyniki:
Uwaga rozdzielczość na obu z nich jest naprawdę dobra.
IOS SIMULATOR, running frame rate counts (in milliseconds (*1000.0))
MACH_ABS_TIME/NSTimeIntervals
58.557001/58.552980
40.558007/40.562987
52.207822/52.200019
33.742197/33.742011
38.498912/38.504004
48.872679/48.868001
45.012602/45.011997
57.858432/57.865977
25.044615/25.038004
IPAD HARDWARE SAMPLINGS:
33.415041/33.416033
33.240167/33.239007
33.357542/33.357978
33.302833/33.302009
33.506750/33.509016
33.582250/33.582985
33.233958/33.232987
33.239042/33.237994
* Jeśli spojrzeć na historię edycji tego postu, można zobaczyć niebezpieczeństwa używając float
w miejscu o double
!
Dlaczego po prostu nie używać 'getrusage()'? Wszystko, co działa w C, działa w Objective-C. –
Ponieważ istnieje całkiem dobra metoda kakao do robienia tego samego. – lucius