Ecco la mia risposta per i timer utilizzando sia mach_absolute_time()
, in base al metodo di calcolo shown here e NSDate
. In realtà sono gli stessi in termini di precisione.
Mach versione
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 versione
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
}
Risultati:
Nota la risoluzione su entrambi questi è veramente buono.
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
* Se si guarda alla storia di modifica di questo post, è possibile vedere il pericolo di usare float
al posto di un double
!
Perché non usare semplicemente 'getrusage()'? Qualunque cosa funzioni in C funzionerà in Objective-C. –
Perché esiste un metodo Cocoa perfettamente valido per fare la stessa cosa. – lucius