冒泡排序和选择排序执行时间的比较 我有一个程序，比较冒泡排序和选择排序的执行时间。 要找出一个代码块的执行时间，计算该代码块之前和之后的时间

 clock_t start=clock();
 …
 clock_t end=clock();
 CLOCKS_PER_SEC is constant in time.h library

示例代码:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main()
{
   int a[10000],i,j,min,temp;
   for(i=0;i<10000;i++)
   {
      a[i]=rand()%10000;
   }
   //The bubble Sort
   clock_t start,end;
   start=clock();
   for(i=0;i<10000;i++)
   {
     for(j=i+1;j<10000;j++)
     {
       if(a[i]>a[j])
       {
         int temp=a[i];
         a[i]=a[j];
         a[j]=temp;
       }
     }
   }
   end=clock();
   double extime=(double) (end-start)/CLOCKS_PER_SEC;
   printf("\n\tExecution time for the bubble sort is %f seconds\n ",extime);

   for(i=0;i<10000;i++)
   {
     a[i]=rand()%10000;
   }
   clock_t start1,end1;
   start1=clock();
   // The Selection Sort
   for(i=0;i<10000;i++)
   {
     min=i;
     for(j=i+1;j<10000;j++)
     {
       if(a[min]>a[j])
       {
         min=j;
       }
     }
     temp=a[min];
     a[min]=a[i];
     a[i]=temp;
   }
   end1=clock();
   double extime1=(double) (end1-start1)/CLOCKS_PER_SEC;
   printf("\n");
   printf("\tExecution time for the selection sort is %f seconds\n\n", extime1);
   if(extime1<extime)
     printf("\tSelection sort is faster than Bubble sort by %f seconds\n\n", extime - extime1);
   else if(extime1>extime)
     printf("\tBubble sort is faster than Selection sort by %f seconds\n\n", extime1 - extime);
   else
     printf("\tBoth algorithms have the same execution time\n\n");
}

你想要这样:

#include <sys/time.h>

struct timeval  tv1, tv2;
gettimeofday(&tv1, NULL);
/* stuff to do! */
gettimeofday(&tv2, NULL);

printf ("Total time = %f seconds\n",
         (double) (tv2.tv_usec - tv1.tv_usec) / 1000000 +
         (double) (tv2.tv_sec - tv1.tv_sec));

请注意，这个度量单位是微秒，而不是秒。

您必须考虑到，测量程序执行所花费的时间在很大程度上取决于机器在特定时刻的负载。

我们知道，在C语言中获取当前时间的方法有不同的方法，更简单的方法是:

#include <time.h>

#define CPU_TIME (getrusage(RUSAGE_SELF,&ruse), ruse.ru_utime.tv_sec + \
  ruse.ru_stime.tv_sec + 1e-6 * \
  (ruse.ru_utime.tv_usec + ruse.ru_stime.tv_usec))

int main(void) {
    time_t start, end;
    double first, second;

    // Save user and CPU start time
    time(&start);
    first = CPU_TIME;

    // Perform operations
    ...

    // Save end time
    time(&end);
    second = CPU_TIME;

    printf("cpu  : %.2f secs\n", second - first); 
    printf("user : %d secs\n", (int)(end - start));
}

希望能有所帮助。

的问候!

原味的C:

#include <time.h>
#include <stdio.h>

int main()
{
    clock_t tic = clock();

    my_expensive_function_which_can_spawn_threads();

    clock_t toc = clock();

    printf("Elapsed: %f seconds\n", (double)(toc - tic) / CLOCKS_PER_SEC);

    return 0;
}

很多答案都建议使用clock()，然后是time.h中的CLOCKS_PER_SEC。这可能是一个坏主意，因为这是我的/bits/time.h文件所写的:

/* ISO/IEC 9899:1990 7.12.1: <time.h>
The macro `CLOCKS_PER_SEC' is the number per second of the value
returned by the `clock' function. */
/* CAE XSH, Issue 4, Version 2: <time.h>
The value of CLOCKS_PER_SEC is required to be 1 million on all
XSI-conformant systems. */
#  define CLOCKS_PER_SEC  1000000l

#  if !defined __STRICT_ANSI__ && !defined __USE_XOPEN2K
/* Even though CLOCKS_PER_SEC has such a strange value CLK_TCK
presents the real value for clock ticks per second for the system.  */
#   include <bits/types.h>
extern long int __sysconf (int);
#   define CLK_TCK ((__clock_t) __sysconf (2))  /* 2 is _SC_CLK_TCK */
#  endif

因此，CLOCKS_PER_SEC可能定义为1000000，这取决于用于编译的选项，因此它似乎不是一个好的解决方案。

我发现通常的clock()，这里每个人都推荐，由于某种原因在一次运行中严重偏离，即使对于静态代码也没有任何副作用，如绘制到屏幕或读取文件。这可能是因为CPU改变了功耗模式，操作系统给出了不同的优先级，等等…

因此，每次使用clock()都可靠地获得相同结果的唯一方法是在循环中多次运行测量的代码(持续几分钟)，并采取预防措施防止编译器对其进行优化:现代编译器可以预先计算在循环中运行的代码而不会产生副作用，并将其移出循环。例如，每次迭代都使用随机输入。

在一个数组中收集了足够多的样本后，对数组进行排序，并取中间的元素，称为中位数。中位数比平均值好，因为它排除了极端偏差，比如反病毒病毒占用了所有CPU或操作系统进行了一些更新。

这里有一个简单的实用程序来测量C/ c++代码的执行性能，平均值接近中值:https://github.com/saniv/gauge

我自己仍然在寻找一种更健壮、更快的方法来度量代码。人们可能会尝试在没有任何操作系统的情况下在受控条件下运行代码，但这会产生不切实际的结果，因为在现实中操作系统确实涉及到。

x86有这些硬件性能计数器，包括实际执行的指令数量，但是如果没有操作系统的帮助，它们很难访问，很难解释，并且有自己的问题(http://archive.gamedev.net/archive/reference/articles/article213.html)。尽管如此，他们仍然可以帮助调查瓶颈的性质(数据访问或对数据的实际计算)。