C语言并不总是更快。

C语言比现代Fortran语言慢。

在某些方面，C通常比Java慢。(特别是在JIT编译器对您的代码进行了测试之后)

C允许发生指针混叠，这意味着一些好的优化是不可能的。特别是当您有多个执行单元时，这将导致数据获取停滞。噢。

指针算术工作的假设确实会导致某些CPU系列(特别是PIC !)它曾经在x86上很差劲。

基本上，当你得到一个矢量单元，或者一个并行编译器，C语言很糟糕，而现代的Fortran运行得更快。

C程序员的一些技巧，比如thking(动态修改可执行文件)会导致CPU预取暂停。

明白我的意思了吗?

而我们的好朋友x86执行的指令集，如今与实际的CPU架构关系不大。影子寄存器，负载存储优化器，都在CPU中。所以C离虚拟金属很近。真正的金属，英特尔不会让你看到。(从历史上看，VLIW CPU有点破产，所以，也许这并不是那么糟糕。)

如果你在高性能DSP上用C编程(可能是TI DSP ?)，编译器必须做一些棘手的事情，在多个并行执行单元之间展开C。因此，在这种情况下，C语言并不接近金属，但它接近编译器，它将进行整个程序优化。奇怪。

最后，一些cpu (www.ajile.com)在硬件中运行Java字节码。C将在该CPU上使用一个PITA。

如果你花了一个月的时间用C语言构建的程序只需要0.05秒，而我花了一天的时间用Java写同样的程序，只需要0.10秒，那么C语言真的更快吗?

但是回答你的问题，编写良好的C代码通常会比其他语言编写的代码运行得更快，因为编写良好的C代码的一部分包括在接近机器的级别上进行手动优化。

尽管编译器确实非常聪明，但它们还不能创造性地提出与手工按摩算法竞争的代码(假设“手”属于一个优秀的C程序员)。

编辑:

很多评论都是这样的:“我用C语言编写，我不考虑优化。”

举个具体的例子:

在Delphi中我可以这样写:

function RemoveAllAFromB(a, b: string): string;
var
  before, after :string;
begin
  Result := b;
  if 0 < Pos(a,b) then begin
    before := Copy(b,1,Pos(a,b)-Length(a));
    after := Copy(b,Pos(a,b)+Length(a),Length(b));
    Result := before + after;
    Result := RemoveAllAFromB(a,Result);  //recursive
  end;
end;

用C语言写:

char *s1, *s2, *result; /* original strings and the result string */
int len1, len2; /* lengths of the strings */
for (i = 0; i < len1; i++) {
   for (j = 0; j < len2; j++) {
     if (s1[i] == s2[j]) {
       break;
     }
   }
   if (j == len2) {  /* s1[i] is not found in s2 */
     *result = s1[i]; 
     result++; /* assuming your result array is long enough */
   }
}

但是C版本中有多少优化呢?我们在实现方面做了很多我在Delphi版本中没有考虑到的决定。字符串是如何实现的?在特尔斐我看不出来。在C语言中，我已经决定它将是一个指向ASCII整数数组的指针，我们称之为字符。在C语言中，我们每次测试一个字符的存在性。在Delphi中，我使用Pos。

这只是一个小例子。在一个大型程序中，C程序员必须对每几行代码做出这类低级决策。它加起来就是一个手工制作、手工优化的可执行文件。

这些答案中的许多都给出了为什么C更快或更快的有效理由(无论是在一般情况下还是在特定的场景中)。不可否认的是:

Many other languages provide automatic features that we take for granted. Bounds checking, run-time type checking, and automatic memory management, for example, don't come for free. There is at least some cost associated with these features, which we may not think about—or even realize—while writing code that uses these features. The step from source to machine is often not as direct in other languages as it is in C. OTOH, to say that compiled C code executes faster than other code written in other languages is a generalization that isn't always true. Counter-examples are easy to find (or contrive).

尽管如此，我还是注意到另一件事，我认为它比其他任何因素都更能影响C与许多其他语言的比较性能。即:

其他语言通常更容易编写执行较慢的代码。通常，它甚至受到该语言的设计哲学的鼓励。推论:C程序员更有可能编写不执行不必要操作的代码。

例如，考虑一个简单的Windows程序，其中创建了一个主窗口。C版本将填充一个WNDCLASS[EX]结构，该结构将传递给RegisterClass[EX]，然后调用CreateWindow[EX]并进入消息循环。以下是高度简化和缩写的代码:

WNDCLASS wc;
MSG      msg;

wc.style         = 0;
wc.lpfnWndProc   = &WndProc;
wc.cbClsExtra    = 0;
wc.cbWndExtra    = 0;
wc.hInstance     = hInstance;
wc.hIcon         = NULL;
wc.hCursor       = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1);
wc.lpszMenuName  = NULL;
wc.lpszClassName = "MainWndCls";

RegisterClass(&wc);

CreateWindow("MainWndCls", "", WS_OVERLAPPEDWINDOW | WS_VISIBLE,
             CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

while(GetMessage(&msg, NULL, 0, 0)){
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

c#中类似的程序可能只有一行代码:

Application.Run(new Form());

这一行代码提供了近20行C代码所提供的所有功能，并添加了一些我们遗漏的功能，例如错误检查。这个更丰富、更完整的库(与典型C项目中使用的库相比)为我们做了很多工作，解放了我们的时间来编写更多的代码片段，这些代码对我们来说很短，但涉及到幕后的许多步骤。

但是，一个丰富的库使简单快速的代码膨胀并不是我真正想要的。当您开始检查我们的小一行程序实际执行时实际发生了什么时，我的观点就更加明显了。为了好玩，可以在Visual Studio 2008或更高版本中启用. net源代码访问，然后进入上面简单的一行代码。您将遇到的一个有趣的小珍宝是Control的getter中的这个注释。CreateParams:

// In a typical control this is accessed ten times to create and show a control.
// It is a net memory savings, then, to maintain a copy on control.
// 
if (createParams == null) {
    createParams = new CreateParams(); 
} 

十次。信息大致相当于存储在WNDCLASSEX结构中的内容和传递给CreateWindowEx的内容的总和，在它存储在WNDCLASSEX结构中并传递给RegisterClassEx和CreateWindowEx之前，从Control类中检索10次。

总而言之，在c#中执行这个非常基本的任务的指令数量比在C中多2-3个数量级，部分原因是使用了功能丰富的库，这是必然的，而我们简单的C代码只做了我们需要的事情，仅此而已。但部分原因是. net框架的模块化、面向对象的特性导致了大量的重复执行，而过程方法通常可以避免这些重复执行。

我并不是要挑c#或。net框架。我也不是说模块化、泛化、库/语言特性、OOP等等都是不好的东西。我曾经用C语言进行大部分开发，后来用c++，最近用c#。类似地，在使用C之前，我主要使用汇编。我的语言每“提高”一步，我就能在更短的时间内写出更好、更可维护、更健壮的程序。然而，它们的执行速度往往要慢一些。

我猜你忘了汇编语言也是一种语言:)

但是说真的，只有当程序员知道自己在做什么的时候，C程序才会更快。你可以很容易地编写一个C程序，它比用其他语言编写的程序运行得更慢。

C语言之所以更快，是因为它就是这样设计的。它允许你做很多“低级”的事情，帮助编译器优化代码。或者，我们可以说，你程序员负责优化代码。但这通常相当棘手，而且容易出错。

其他语言，就像前面提到的其他语言一样，更关注程序员的生产力。人们普遍认为程序员的时间比机器的时间要昂贵得多(即使在过去)。因此，尽量减少程序员花在编写和调试程序上的时间，而不是减少程序的运行时间，是很有意义的。为了做到这一点，您将牺牲一些可以使程序更快的事情，因为许多事情都是自动化的。

主要的因素是它是一种静态类型的语言，可以编译为机器代码。此外，由于它是一种低级语言，它通常不会做任何您不让它做的事情。

这些是我想到的其他一些因素。

Variables are not automatically initialized No bounds checking on arrays Unchecked pointer manipulation No integer overflow checking Statically-typed variables Function calls are static (unless you use function pointers) Compiler writers have had lots of time to improve the optimizing code. Also, people program in C for the purpose of getting the best performance, so there's pressure to optimize the code. Parts of the language specification are implementation-defined, so compilers are free to do things in the most optimal way

大多数静态类型语言的编译速度可以和C语言一样快，甚至比C语言更快，特别是如果它们可以假设C语言因为指针别名等原因而不能这样做的话。

我知道很多人都说过这句话，但是:

C更快，因为它(为你)做的更少。