为什么我的C程序比它的C#等效速度慢？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了为什么我的C程序比它的C#等效速度慢？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2040字，纯文字阅读大概需要3分钟。

内容图文

我想在C和C#之间做一个小的基准测试,所以我编写了以下程序：

C：

int main()
{
    int i = 1;
    while (i <= 500000)
    {
        printf("%d", i);
        i++;
    }
}

C#：

class Program
    {
        static void Main(string[] args)
        {
            int i = 1;
            while (i <= 500000)
            {
                Console.Write(i);
                i++;
            }
        }
    }

然后我编译它们并同时运行它们.

令我惊讶的是,C#程序比C程序提前了大约5秒.

C是一种以其高速和高性能而闻名的语言,那么在这种情况下,C#程序在如此简单的任务中能够显着优于C程序呢？我认为C#速度慢得多,因为它在运行时编译,但它很容易击败从C编译的本机可执行文件.

这是什么原因,这种情况在其他类型的程序中也会发生吗？

我在Windows 8.1 Pro 64位上运行这两个程序,如果这很重要,并在C#Express 2010中编译C#程序,在VS2013 Express for Desktop中编译C程序.

请不要因为“这么常见的问题”而抨击我 – 是的,我已经看到了另一个答案,但它们都处理了复杂的事情,如内存管理和缓冲区大小,这里的程序非常简单,不需要处理那些事情.

我也尝试用puts替换printf,但那也很慢.

解决方法:

这与C语言或其编译器没有任何关系,与其运行时支持库有关.减速是由您使用printf()引起的.

C运行时库(CRT)严重陷入困境,为可追溯到20世纪70年代的运行时环境建模.当程序员使用电传打字机与计算机交谈时,一个具有非常原始操作系统的计算机不支持线程,用英语交谈.

运行时环境与现代操作系统非常不匹配,需要相当大的开销来模拟它.例如,C语言对Unicode的支持非常差.因此,您输出的每个字符串都必须精心转换为Windows中的本机操作系统字符串格式utf-16. .NET Framework使用System.String,这是一种在utf-16中编码的字符串类型.即使是最低级别,Windows也要求字符串为零终止,就像C字符串需要的那样.每个.NET字符串都自动为零终止,即使是那些不用于I / O的字符串.因此不需要转换,框架可以直接调用输出字符串的操作系统函数.

那不是结束的地方.线程的概念与CRT完全不同,它从未被设计为考虑多线程的分支,例如,修改语言环境或同时编写文本.所以CRT充满了低级锁定,以实现这一目标.实际上很少有用的开销,但必须采用,因为20世纪70年代的运行时模型不会不允许也不会考虑它.

你可以使你的C程序和你的C#程序一样快,使它显着更快有点延伸,但你必须绕过20世纪70年代这样做.使用wprintf()代替已经应该有明显的区别,在调用WriteConsoleW()或WriteFile()之前,你不会得到奇偶校验.

请注意,这实际上并不重要.无论如何,文本在屏幕上滚动的速度远远快于人类可以读取的速度.因此,任何人都不会考虑修复这个问题.

内容总结

以上是互联网集市为您收集整理的为什么我的C程序比它的C#等效速度慢？全部内容，希望文章能够帮你解决为什么我的C程序比它的C#等效速度慢？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端