平常科研当中，当我们在看文献时，没看到一个优秀的算法时都有想要自己动手编程去实现的愿望，算法好坏可以用代码的运行时间来评估，在MATLAB中大致有以下几种方法来计算程序的运行时间：
 
1、tic和toc组合
 
tic
%代码块
toc
%disp(['运行时间: ',num2str(toc)]);
 
程序遇到tic时Matlab自动开始计时，运行到toc时自动计算此时与最近一次tic之间的时间
 
2、etime()与clock组合
 
t1=clock;
%代码块
t2=clock;
etime(t2,t1)
 
计算t1，t2之间的时间差，它是通过调用windows系统的时钟进行时间差计算得到运行时间的。
 
3、cputime函数
 
t0=cputime
%代码块
t1=cputime-t0
 
上以上三种方法，都是可以进行程序运行时间的计算，但是Matlab官方推荐使用tic，toc组合。但是使用tic/toc的时候一定要注意，toc计算的是与最后一次（即离它最近）运行的tic之间的时间。
 
参考：http://www.matlabsky.com/thread-2607-1-1.html?_dsign=33d7d995

1、使用Stopwatch类
 命名空间:System.Diagnostics
 
Stopwatch 实例可以测量一个时间间隔的运行时间，也可以测量多个时间间隔的总运行时间。在典型的 Stopwatch 方案中，先调用 Start 方法，然后调用 Stop 方法，最后使用 Elapsed 属性检查运行时间。
 
Stopwatch 实例或者在运行，或者已停止；使用 IsRunning 可以确定 Stopwatch 的当前状态。使用 Start 可以开始测量运行时间；使用 Stop 可以停止测量运行时间。通过属性 Elapsed、ElapsedMilliseconds 或 ElapsedTicks 查询运行时间值。当实例正在运行或已停止时，可以查询运行时间属性。运行时间属性在 Stopwatch 运行期间稳固递增；在该实例停止时保持不变。
 
默认情况下，Stopwatch 实例的运行时间值相当于所有测量的时间间隔的总和。每次调用 Start 时开始累计运行时间计数；每次调用 Stop 时结束当前时间间隔测量，并冻结累计运行时间值。使用 Reset 方法可以清除现有 Stopwatch 实例中的累计运行时间。
 
Stopwatch 在基础计时器机制中对计时器的刻度进行计数，从而测量运行时间。如果安装的硬件和操作系统支持高分辨率性能的计数器，则 Stopwatch 类将使用该计数器来测量运行时间；否则，Stopwatch 类将使用系统计数器来测量运行时间。使用 Frequency 和 IsHighResolution 字段可以确定实现 Stopwatch 计时的精度和分辨率。
 
Stopwatch 类为托管代码内与计时有关的性能计数器的操作提供帮助。具体说来，Frequency 字段和 GetTimestamp 方法可以用于替换非托管 Win32 API QueryPerformanceFrequency 和 QueryPerformanceCounter。
 
static void Main(string[] args)
{
    System.Diagnostics.Stopwatch oTime = new System.Diagnostics.Stopwatch();   //定义一个计时对象  
    oTime.Start();                         //开始计时 
    System.Threading.Thread.Sleep(5000);   //延时5秒
    oTime.Stop();                          //结束计时
 
    //输出运行时间。  
    Console.WriteLine("程序的运行时间：{0} 秒", oTime.Elapsed.TotalSeconds);
    Console.WriteLine("程序的运行时间：{0} 毫秒", oTime.Elapsed.TotalMilliseconds);
 
    Console.ReadLine();
}

 
2、使用时间函数，求时间差
 
static void Main(string[] args)
{
    DateTime beginTime = DateTime.Now;            //获取开始时间  
    System.Threading.Thread.Sleep(5000);          //延时5秒
    DateTime endTime = DateTime.Now;              //获取结束时间  
    TimeSpan oTime = endTime.Subtract(beginTime); //求时间差的函数  
 
    //输出运行时间。  
    Console.WriteLine("程序的运行时间：{0} 秒", oTime.TotalSeconds);
    Console.WriteLine("程序的运行时间：{0} 毫秒", oTime.TotalMilliseconds);
 
    Console.ReadLine();
}

推荐自己的专栏：分享一些Python案例，将所学用出来
 
 
一：算法时间复杂度分析函数的设计
 
程序的运行时间长度与算法的设计和所求解的问题的规模有关。
当输入大小(即问题规模)增大时，程序的运行时间递增比例，即是算法的时间复杂度。
 
设计思路如下:
 
定义函数buildData(n)，构造并返回规模为n的测试输入数据。例如，排序随机n个数的列表。
 
def buildData(n):
    """构造测试规模为n的输入数据,对于排序，随机n个数的列表"""
    data = [random.randrange(n) for i in range(n)]
    return data
 
定义函数timing(f, data)， 返回调用f(data)的运行时间。
 
def timing(f, data):
    """测量函数调用f(data)的运行时间分析"""
    start = time.time() #记录开始时间
    f(data)  #运行f(data)
    end = time.time()  #记录结束时间
    return end - start #返回执行时间
 
定义函数timingAnalysis(f, m1, m2, runs, buildData)， 测量并输出函数 f 在不同输入规模: 10m1、10m1+1、 …、10m2 情况下运行runs次的平均时间。
 函数调用buildData(n)规模为n的数据data，然后调用timing(f, data) 测量函数的运行时间。
 
def timingAnalysis(f,m1, m2, runs, buildData) :
    """输出函数f在不同输入规模: 10**m1,.... ,10**m2运行runs次的时间"""
    for n in [10**i for i in range(m1, m2+1)]:  #10**m1,...，10**m2
          data = buildData (n)
          total = 0.0  #初始化总时间
          for i in range(runs) : #重复运行runs次
              total += timing(f, data) #运行f并累计运行时间
          strResult = '输入规模{:10}时函数{:15}运行{}次的平均时间为: {} 秒'
          print (strResult.format(n, f.__name__, runs, total/runs))
 
在测试代码中，导入各种排序算法（不在本篇文章中赘述，有兴趣者可以下载完整代码查看），然后调用分析各排序算法的时间复杂度。
 
二：算法时间复杂度分析函数的实现与应用
 
time_analysis.py
 
import time
import random

def timing(f, data):
    """测量函数调用f(data)的运行时间分析"""
    start = time.time() #记录开始时间
    f(data)  #运行f(data)
    end = time.time()  #记录结束时间
    return end - start #返回执行时间

def timingAnalysis(f,m1, m2, runs, buildData) :
    """输出函数f在不同输入规模: 10**m1,.... ,10**m2运行runs次的时间"""
    for n in [10**i for i in range(m1, m2+1)]:  #10**m1,...，10**m2
          data = buildData (n)
          total = 0.0  #初始化总时间
          for i in range(runs) : #重复运行runs次
              total += timing(f, data) #运行f并累计运行时间
          strResult = '输入规模{:10}时函数{:15}运行{}次的平均时间为: {} 秒'
          print (strResult.format(n, f.__name__, runs, total/runs))

def buildData(n):
    """构造测试规模为n的输入数据,对于排序，随机n个数的列表"""
    data = [random.randrange(n) for i in range(n)]
    return data


#测试代码

if __name__ ==  "__main__" :
    from bubbleSort import bubbleSort
    from selectionSort import selectionSort
    from insertSort import insertSort
    from mergeSort import mergeSort
    from quickSort import quickSort

    def quickSort1 (a) :
        quickSort(a, 0, len(a) - 1)

    #冒泡排序算法，时间复杂度分析
    timingAnalysis (bubbleSort, 2, 4, 1, buildData)
    print()

    #选择排序算法，时间复杂度分析
    timingAnalysis (selectionSort, 2, 4, 1, buildData)
    print()

    #插入排序算法，时间复杂度分析
    timingAnalysis (insertSort, 2, 4, 1, buildData)
    print()

    #归并排序算法，时间复杂度分析
    timingAnalysis (mergeSort, 1, 4, 1, buildData)
    print()

    #快速排序算法，时间复杂度分析
    timingAnalysis (quickSort1, 1, 4, 1, buildData)
    print()

    #内置排序算法sort，时间复杂度分析
    timingAnalysis(sorted, 1, 4, 1, buildData)

 
运行：
 
输入规模       100时函数bubbleSort     运行1次的平均时间为: 0.000997781753540039 秒
输入规模      1000时函数bubbleSort     运行1次的平均时间为: 0.10474658012390137 秒
输入规模     10000时函数bubbleSort     运行1次的平均时间为: 8.514265298843384 秒

输入规模       100时函数selectionSort  运行1次的平均时间为: 0.0 秒
输入规模      1000时函数selectionSort  运行1次的平均时间为: 0.044878244400024414 秒
输入规模     10000时函数selectionSort  运行1次的平均时间为: 4.592764377593994 秒

输入规模       100时函数insertSort     运行1次的平均时间为: 0.0009894371032714844 秒
输入规模      1000时函数insertSort     运行1次的平均时间为: 0.0917809009552002 秒
输入规模     10000时函数insertSort     运行1次的平均时间为: 7.810081720352173 秒

输入规模        10时函数mergeSort      运行1次的平均时间为: 0.0 秒
输入规模       100时函数mergeSort      运行1次的平均时间为: 0.000997304916381836 秒
输入规模      1000时函数mergeSort      运行1次的平均时间为: 0.0029914379119873047 秒
输入规模     10000时函数mergeSort      运行1次的平均时间为: 0.03091740608215332 秒

输入规模        10时函数quickSort1     运行1次的平均时间为: 0.0 秒
输入规模       100时函数quickSort1     运行1次的平均时间为: 0.0009975433349609375 秒
输入规模      1000时函数quickSort1     运行1次的平均时间为: 0.001994609832763672 秒
输入规模     10000时函数quickSort1     运行1次的平均时间为: 0.02396249771118164 秒

输入规模        10时函数sorted         运行1次的平均时间为: 0.0 秒
输入规模       100时函数sorted         运行1次的平均时间为: 0.0 秒
输入规模      1000时函数sorted         运行1次的平均时间为: 0.0 秒
输入规模     10000时函数sorted         运行1次的平均时间为: 0.0019676685333251953 秒

来源：https://www.cnblogs.com/kosmanthus/articles/1423466.html
 
前言
 
对于一个嵌入式程序员来说，“我的程序到底运行多快”，是我们最为关心的问题，因为速度，实时性，永远是嵌入式设备性能优化的基本立足点之一。 可惜的是，我们平时常用的测试运行时间的方法，并不是那么精确的。换句话说，想精确获取程序运行时间，不是那么容易的。也许你会想，程序不就是一条条指令 么，每一条指令序列都有固定执行时间，为什么不好算？真实情况下，我们的计算机并不是只运行一个程序的，进程的切换，各种中断，共享的多用户，网络流量， 高速缓存的访问，转移预测等，都会对计时产生影响。

 可惜的是，在性能测量领域，我们有gprof，有intel的vtune，却缺少相应 的，广泛流传的参考文献。如果你希望能建立起自己的工具，或者对具体的测量方式感兴趣，那么本文也许会对你有帮助。我想，应该有很多人希望知道计时机制的 原理，因为针对不同的系统，环境，会有不同的解决方案。本文主要针对Linux和X86体系环境，主要思想来源于"Computer System A Programmer's Perspective"，夹杂了一些自己的理解，并试图给出我自己写的一个通用测量工具，支持用户自配置。本文有时的对象是程序有时描述对象是进程，这个请自行理解，因为一个程序就是在一个进程里面执行的。
  
 
进程调度和模式切换
 
在介绍具体方法之前，先简单说几句。

 对 于进程调度来讲，花费的时间分为三部分，第一是计时器中断处理的时间，也就是当且仅当这个时间间隔的时候，操作系统会选择，是继续当前进程的执行，还是切 换到另外一个进程中去。第二是进程切换时间，当系统要从进程A切换到进程B时，它必须先进入内核模式将进程A的状态保存，然后恢复进程B的状态。因此，这 个切换过程是有内核活动来消耗时间的。第三就是进程的具体执行时间了，这个时间也包括内核模式和用户模式两部分，模式之间的切换也是需要消耗时间，不过都 算在进程执行时间中了。

 其实模式切换非常费时，这也是很多程序中都要采用缓冲区的原因，例如，如果每读一小段文件什么的就要调用一次 read之类的内核函数，那太受影响了。所以，为了尽量减少系统调用，或者说，减少模式切换的次数，我们向程序（特别是IO程序）中引入缓冲区概念，来缓 解这个问题。

 一般来说呢，向处理器发送中断信号的计时器间隔通常是1-10ms，太短，切换太多，性能可能会变差，太长呢，如果在任务间切换频繁，又无法提供在同时执行多任务的假象。这个时间段，也决定了一些我们下面要分析的不同方法衡量时间的差异。
  
 
方法一：间隔计数
 
我 们都知道，Linux下有一个命令是专门提供一个进程的运行时间的，也就是time。time可以测量特定进程执行时所需消耗的时间及系统资源等，这个时 间还可以分内核时间和用户态时间两部分呈现给你。它是怎么做到的呢？其实很简单，操作系统本身就是用计时器来记录每个进程使用的累计时间，原理很简单，计 时器中断发生时，操作系统会在当前进程列表中寻找哪个进程是活动的，一旦发现，哟，进程A跑得正欢，立马就给进程A的计数值增加计时器的时间间隔（这也是 引起较大误差的原因，想想）。当然不是统一增加的，还要确定这个进程是在用户空间活动还是在内核空间活动，如果是用户模式，就增加用户时间，如果是内核模 式，就增加系统时间。

 原理很简单吧？但是相信一点，越简单的东西，是不会越精确的，人品守恒，能量守恒，难度也当然会守恒了啊。下面就简 单分析一下，为啥这玩意精度不高吧。举个例子，如果我们有一个系统，计时器间隔为10ms，系统里面跑了一个进程，然后我们用这种方法分析时间，测出 70ms，想一想，实际会有几种结果？具体点，我们用这种方法对进程计时，在某个计时器中断时，系统发现，咦，有一个进程开始跑了，好，给进程的计数值加 上10ms。但是实际上呢，这个进程可能是一开始就跑起来了，也肯能是在中断的前1ms才开始跑的。不管是什么原因，总之中断时候它在跑，所以就得加 10ms。当中断发生时发现进程切换了，同理，可能是上一个中断之后1ms进程就切换了，也可能人家刚刚才切换。

 所以呢，如果一个进程的 运行时间很短，短到和系统的计时器间隔一个数量级，用这种方法测出来的结果必然是不够准确的，头尾都有误差。不过如果程序的时间足够长，这种误差有时能够 相互弥补，一些被高估一些被低估，平均下来刚好，呵呵。从理论上，我们很难分析这个误差的值，所以一般只有程序到达秒的数量级时，用这种方式测试程序时间 才有意义。

 说了半天，难道这方法没优点了？不，这个世界没有纯善，也没有纯恶。这方法最大的优点是，它的准确性不是非常依赖于系统负载。那什么方法依赖于系统负载呢？接下来我们会讲到：）

 理论陈述结束，我想应该开始关注实现方法了吧。其实超级简单，两种方法：
  
 
直接调用time命令（一堆鸡蛋）
使用tms结构体和times函数
说说正经点的第二个方法吧。在Linux中，提供了一个times函数，原型是

 clock_t times( struct tms *buf )

 这个tms的结构体为

 struct tms
 {
     clock_t tms_utime;       // user time
     clock_t tms_stime;       // system time
     clock_t tms_cutime;     // user time of reaped children
     clock_t tms_cstime;     // system time of reaped children
 }

 怎么使用就不用这里教了吧？不过要说明一下的是，这里的cutime和cstime，都是对已经终止并回收的时间的累计，也就是说，times不能监视任何正在进行中的子进程所使用的时间。
  
 
方法二：周期计数
 

 刚 才谈了半天间隔计数的不足之处，哪有不足，那就有弥补的方法，特别实在万能的Linux中:) 为了给计时测量提供更高的准确度，很多处理器还包含一个运行在时钟周期级别的计时器，它是一个特殊的寄存器，每个时钟周期它都会自动加1。这个周期计数器 呢，是一个64位无符号数，直观理解，就是如果你的处理器是1GHz的，那么需要570年，它才会从2的64次方绕回到0，所以你大可不必考虑“万一溢出 怎么办”此类问题。

 看到这里，也许你会想，哇塞，很好很强大嘛，时钟周期，这都精确到小数点后面多少位来着了？这下无论是多快的用时多短 的程序，我们也都能进行时间测量了。Ohyeah。等等，刚才我们说过什么来着？守恒定律啊！功能强大的东西，其他方面必有限制嘛。看到上面的介绍，聪明 的你一定能猜出来这种方法的限制是什么了，那就是，hardware dependent。首先，并不是每种处理器都有这样的寄存器的，其次，即使大多数都有，实现机制也不一样，因此，我们无法用统一的，与平台无关的接口来 使用它们。怎么办？这下，就要祭出上古传说中的神器：汇编了。当然，我们在这里实际用的是C语言的嵌入汇编：

 void counter( unsigned *hi, unsigned *lo )
 {
 asm("rdtsc; movl %%edx,%0; movl %%eax, %1"
         : "=r" (*hi), "=r" (*lo)
         :
         : "%edx", "%eax");
 }

 第一行的指令负责读取周期计数器，后面的指令表示将其转移到指定地点或寄存器。这样，我们将这段代码封装到函数中，就可以在需要测量的代码前后均加上这个函数即可。最后得到的hi和lo值都是两个，除了相减得到间隔值外，还要进行一些处理，在此先按下不表。

 不 得不提出的是，周期计数方式还有一个问题，就是我们得到了两次调用counter之间总的周期数，但我们不知道是哪个进程使用了这些周期，或者说处理器是 在内核还是在用户模式中。还记得刚才我们讲间隔计数方式么？这玩意的好处就是它是操作系统控制给进程计时的，我们可以知道具体哪个进程，哪个模式。但是周 期计数只测量经过的时间，他不管你是哪个进程使用的。所以，用周期计数的话，我们必须很小心。举个例子

 double time()
 {
      start_counter();
      p();
      get_counter();
 }

 这样一段程序，如果机器的负载很重，会导致P运行时间很长，而其实P函数本身是不需要运行这么长时间的，而是上下文切换等过程将它的时间拖长了。

 而且，转移预测（想一想，如果转移方向和目的预测错误）和高速缓存的命中率，对这个计数值也会有影响。通常情况下，为了减少高速缓存不命中给我们程序执行时间带来的影响，可以执行这样的代码：

 double time_warm( void )
 {
      p();
      start_counter();
      p();
      get_counter();
 }

 原因不用我再解释了吧？它让指令高速缓存和数据高速缓存都得到了warm-up。

 好，接下来又有问题。如果我们的应用，是属于那种每次执行都希望访问新的数据的那种呢？在这种情况下，我们希望让指令高速缓存warm-up，而数据高速缓存不能warm-up，很明显，time_warm函数低估我们的运行时间了。让我们进行进一步修改：

 double time_cold( void )
 {
      p();
      clear_cache();
      start_counter();
      p();
      get_counter();
 }

 注意，我们加入了一个清除数据缓存的函数。这个函数的具体实现很简单，依情况而定，比如举个例子

 volatile int tmp;
 static int dummy[N];      // N是你需要清理缓存的字节数

 void clear_cache( void )
 {
      inti, sum = 0;
      for( i=1;i<N;i++ )
           dummy[i] = 2;
      for( i=1;i<N;i++ )
           sum += dummy[i];
      tmp = sum;
 }

 具体原理很简单，我们在定义一个数组并在其上执行一个计算，计算过程中的数据会覆盖高速数据缓存中原有的数据。每一次的store和load都会让高速数据缓存cache这个数组，而定义为volatile的tmp则保证这段代码不会被优化。

 这样做，是不是就万无一失了呢？不是的，因为大多数处理器，L2高速缓存是不分指令和数据的，这样clear_cache会让所有P的指令也被清除，只不过：L1缓存中的指令还会保留而已。

 其实上面提到的诸多原因，都是我们不能控制的，我们无法控制让高速缓存去加载什么，不去加载什么，加载时去掉什么，保留什么。而且，这些误差通常都是会过高估计真实的运行时间。那么具体使用时，有没有什么办法来改善这种情况呢？有，就是The K-Best Measurement Scheme。这玩意其实很麻烦，所以我在具体实践中都不用它，附上一个文档，有兴趣的朋友可以下载下来看一下。

 我不喜欢间隔计数的小适用范围，也不喜欢周期计数的麻烦性，相信读到这里的99%的读者也和我一种感受吧。OK，最后我们要介绍的，就是一个可移植性更好，相对较准确的方法。
  
 
方法三：gettimeofday函数计时
 

 gettimeofday是一个库函数，包含在time.h中。它的功能是查询系统时钟，以确定当前的日期和时间。它很类似于刚才所介绍的周期计时，除了测量时间是以秒为单位，而不是时钟周期为单位的。原型如下：

 struct timeval
 {
 long tv_sec;
 long tv_usec;
 }

 int gettimeofday( struct timeval *tv, NULL )

 这 个机制呢，具体的实现方式在不同系统上是不一样的，而且虽然披着一个usec（us）的老虎皮，其实没这么精确。具体的精确程度，是和系统相关的，比如在 Linux下，是用周期计数来实现这个函数的，所以和周期计数的精确度差不多，但是在Windows NT下，使用间隔计数实现的，精确度就很低了（所以啊，万恶的ms啊)。

 具体使用的时候，就是开始来一个gettimeofday( tvstart, NULL )，结束来一个gettimeofday( tvend, NULL )，完了sec域和usec域相减的差值就是计时时间。

 如何，很方便吧？应该说在Linux下，这是最有效而方便的计时方式了。从测试情况看，精确度也不错。这种价格便宜量又足的东西嘛，大家可以随便多用。
  
 
总结
 
这次的总结很简单：没有一个计时方法是完美的，我们所要作的，就是理解本质后，在特定的系统上去寻找特定的好方法。