2008-10-15 38 views

回答

7

除非这两段代码中的一段已经在您的应用中,您已经对应用的整体性能进行了剖析,以确定现有代码是一个主要瓶颈,那么您所做的就是所谓的“过早优化“。

Xcode中包括一个极好的工具profiler称为 “Shark。”对于某些版本,它位于/ Developer/Applications中;对于其他人,它位于“性能工具”子目录中。

鲨鱼会告诉你到底有多少时间,作为整体执行时间的百分比,您的应用程序在代码中的每个部分的支出。使用像鲨鱼的工具的思路是遵循“80/20法则” - 您的应用程序将花费其80%的时间运行其代码的20%,所以为了达到最佳效果,你应该花的时间80%优化相同的20%。

因此,要直接回答你的问题,假设你有运行鲨鱼,而你正在寻找最优化最上面的瓶颈,只需用优化的代码替换它,并再次运行鲨鱼在你的应用程序。然后,比较在替换代码中花费的总时间与原始代码的百分比。

+0

绝对使用鲨鱼 - 这是你一直想要和最终拥有的性能工具。谢尔姆的链接是用户指南。绝对要经历它。技术说明2086是另一个很好的参考:http://developer.apple.com/technotes/tn/tn2086.html – heckj 2008-10-15 22:08:33

2

呜鲨,耶。另见Shark Remote Control。基本上,从鲨鱼菜单中选择Sampling > Programmatic (Remote),然后调用chudStartRemotePerfMonitor和chudStopRemotePerfMonitor()括起您想要分析的特定代码。

这且不说,这里有一段代码,我想留做日后时机。

首先使用

uint64_t startTime, stopTime; 
startTime = mach_absolute_time(); 

< work to time goes here > 

stopTime = mach_absolute_time(); 
logMachTime_withIdentifier_(stopTime - startTime, @"10000000 class messages"); 

和这里的辅助功能,logMachTime_withIdentifier_

#import <mach/mach_time.h> 
void logMachTime_withIdentifier_(uint64_t machTime, NSString *identifier) { 
    static double timeScaleSeconds = 0.0; 
    if (timeScaleSeconds == 0.0) { 
     mach_timebase_info_data_t timebaseInfo; 
     if (mach_timebase_info(&timebaseInfo) == KERN_SUCCESS) { // returns scale factor for ns 
      double timeScaleMicroSeconds = ((double) timebaseInfo.numer/(double) timebaseInfo.denom)/1000; 
      timeScaleSeconds = timeScaleMicroSeconds/1000000; 
     } 
    } 

    NSLog(@"%@: %g seconds", identifier, timeScaleSeconds*machTime); 
} 
1

假设你要分析整个应用程序(不只是一小段代码),并且您的应用程序是用C/C++/Objective-C的(不,如红宝石),而且你使用Xcode 3.0或更高版本,您还应该查看Instruments应用程序。 “采样器”乐器会给你非常类似的信息鲨鱼(虽然没有鲨鱼有时非常提高性能有用的提示)。此外,您可以跟踪其他资源利用率(GC,核心数据,网络,磁盘I/O等),这些可能是应用程序性能比代码效率更重要的决定因素(同样取决于应用程序)。仪器也可以使用OS X 10.5(man dtrace)中的DTrace支持。您可以使用DTrace编写自己的工具来更具体地监视应用程序(例如调用一个或多个方法)。

使用NSLog是个坏主意,正如您怀疑的那样,因为它可能会使用Apple系统日志记录系统。在向asl写入日志时出现非确定性延迟,并在控制台中显示。我不确定何时设置时间戳。