c#不可忍受之慢—谁是罪魁祸首

C#性能瓶颈三大罪魁祸首:对象分配、数据搬运与同步阻塞 在.NET开发中,'C#很慢'往往并非语言或运行时缺陷,而是由高频堆分配、冗余数据序列化/反序列化、以及同步IO滥用这三类基础性问题引发的性能退化。其底层原理涉及GC代际回收机制失衡、内存拷贝路径过长、线程池资源耗尽等系统级现象,技术价值在于通过零成本诊断工具(如dotnet-counters、PerfView)实现可复现、可量化、可优化的性能治理。典型应用场景覆盖报表导出卡顿、API响应毛刺、高并发下内存暴涨等生产常见问题,本文聚焦真实业务代码中的'慢写法',结合StringBuilder、Span<T> 阅读详情
    前些日子,爆出N篇说c#/.net太慢的,要求删除c#/.net部分特性的文章。

    撇开那些文章不说,c#/.net慢似乎是业界公认的铁则,不论大家如何证明c#/.net其实不比c++慢多少,但是应用程序级别的性能却依然这么慢。

    那么c#/.net慢在哪里?

    很不幸的是大部分c#程序是被大部分程序员拖慢的,也许这个结论不太容易被人接受,却是一个广泛存在的。

String的操作

    几乎所有的程序都有String操作,至少90%的程序需要忽略大小写的比较,检查一下代码,至少其中大半的应用程序有类似这样的代码:

if (str1.ToUpper() == str2.ToUpper())

    或者ToLower版的,甚至我还看到过有个Web的HttpModule里面写上了:

for (int i = 0; i < strs.Count; i++)
    if (value.ToUpper() == strs[i].ToUpper())
        //...

    想一下,每个页面请求过来,都要执行这样一段代码,大片大片的创建string实例,更夸张的是还有人说这是用空间换时间。。。

性能测试

    说这个方法慢,也许还有人不承认,认为这个就是最好的方法,所以这里要用具体测试来摆个事实。

    首先准备一个测试性能的方法:

private static TResult MeasurePerformance<TArg, TResult>(Func<TArg, TResult> func, TArg arg, int loop)
{
    GC.Collect();
    int gc0 = GC.CollectionCount(0);
    int gc1 = GC.CollectionCount(1);
    int gc2 = GC.CollectionCount(2);
    TResult result = default(TResult);
    Stopwatch sw = Stopwatch.StartNew();
    for (int i = 0; i < loop; i++)
    {
        result = func(arg);
    }
    Console.WriteLine(sw.ElapsedMilliseconds.ToString() + "ms");
    Console.WriteLine("GC 0:" + (GC.CollectionCount(0) - gc0).ToString());
    Console.WriteLine("GC 1:" + (GC.CollectionCount(1) - gc1).ToString());
    Console.WriteLine("GC 2:" + (GC.CollectionCount(2) - gc2).ToString());
    return result;
}

    然后来准备一个堆string:

private static List<string> CreateStrings()
{
    List<string> strs = new List<string>(10000);
    char[] chs = new char[3];
    for (int i = 0; i < 10000; i++)
    {
        int j = i;
        for (int k = 0; k < chs.Length; k++)
        {
            chs[k] = (char)('a' + j % 26);
            j = j / 26;
        }
        strs.Add(new string(chs));
    }
    return strs;
}

    然后来看看ToUpper的实现:

private static bool ImplementByToUpper(List<string> strs, string value)
{
    for (int i = 0; i < strs.Count; i++)
        if (value.ToUpper() == strs[i].ToUpper())
            return true;
    return false;
}

    最后准备好main方法:

List<string> strs = CreateStrings();
bool result;
Console.WriteLine("Use ImplementByToUpper");
result = MeasurePerformance(s => ImplementByToUpper(strs, s), "yZh", 1000);
Console.WriteLine("result is " + result.ToString());
Console.ReadLine();

    来看看执行结果:

Use ImplementByToUpper
2192ms
GC 0:247
GC 1:0
GC 2:0
result is True

    来个对比测试,用string.Equals来测试一下:

private static bool ImplementByStringEquals(List<string> strs, string value)
{
    for (int i = 0; i < strs.Count; i++)
        if (string.Equals(value, strs[i], StringComparison.CurrentCultureIgnoreCase))
            return true;
    return false;
}

    来看看执行结果:

Use ImplementByStringEquals
1117ms
GC 0:0
GC 1:0
GC 2:0
result is True

    对比一下,使用ToUpper的速度要慢一倍,并且有大量的0代垃圾对象。那些号称是用空间换时间的人可以反思一下了,用空间换来了什么?负时间吗?

字典类的使用

    继续说string的场景,有些人也许会想到用Hash表等类似结构来加速,不错,这是个好主意,只不过,Hash表不一定总是最佳方案,什么不相信?还是做个测试吧:

private static bool ImplementByHashSet(List<string> strs, string value)
{
    HashSet<string> set = new HashSet<string>(strs, StringComparer.CurrentCultureIgnoreCase);
    return set.Contains(value);
}

    看看执行结果:

Use ImplementByHashSet
5114ms
GC 0:38
GC 1:38
GC 2:38
result is True

    惊讶吧,速度比用ToUpper还慢了1倍多,而且2代垃圾也38次的回收(执行2代垃圾回收时,会强制执行1代和0代垃圾回收)。

    不过使用Hash表等类似来加速这个想法本身是一个很正确的想法,不过前提是Hash表本身能够缓存,例如:

private static Func<string, bool> ImplementByHashSet2(List<string> strs)
{
    HashSet<string> set = new HashSet<string>(strs, StringComparer.CurrentCultureIgnoreCase);
    return set.Contains;
}

    然后把main的方法修改为:

Console.WriteLine("Use ImplementByHashSet2");
result = MeasurePerformance(s =>
{
    var f = ImplementByHashSet2(strs);
    bool ret = false;
    for (int i = 0; i < 1000; i++)
    {
        ret = f(s);
    }
    return ret;
}, "yZh", 1);
Console.WriteLine("result is " + result.ToString());
Console.ReadLine();

    再看看结果:

Use ImplementByHashSet2
6ms
GC 0:0
GC 1:0
GC 2:0
result is True

    性能出现了飞跃性的增长。

更多

    是什么拖慢了c#/.net?简单的说:不必要的创建对象,不必要的同步,循环执行低效的方法(例如被firelong重点批斗的反射,不过ms并没让你在循环里面使用Invoke),使用低效的数据结构和算法(看看缓存情况下Hash表类似结构的惊人表现,就知道区别了)

    c#/.net的低门槛确实在一定程度上有利于把更多的程序员拉入c#/.net,但是也确实把整个c#/.net程序的代码水平降低了不少,这一点确实很令人担忧。

    最后别忘了一点,一个系统能有多少性能,不是由这个系统中性能最好的部分决定的,而是由这个系统中性能最差的部分所决定的。配一台有16g内存,100t硬盘,加上顶级的显卡,缺配上386的cpu,这台电脑的性能就是386的性能。同样,c#/.net再好,写程序的人水平差,写出来的程序的性能自然也就差了。

C# 更改皮肤 简介: ☆ 资料说明: ☆ 窗体更换皮肤; 自定义皮肤 立即下载

相关推荐

专技在线听课挂机软件

可以挂线听课计时,减少时间浪费,听课时不用整天坐在电脑前

c#不可忍受之慢——谁是罪魁祸首

    前些日子,爆出N篇说c#/.net太慢的,要求删除c#/.net部分特性的文章。     撇开那些文章不说,c#/.net慢似乎是业界公认的铁则,不论大家如何证明c#/.net其实不比c++慢多少,但是应用程序级别的性能却依然这么慢。     那么c#/.net慢在哪里?     很不幸的是大部分c#程序是被大部分程序员拖慢的,也许这个结论不太容易被人接受,却是一个广泛存在的。 St...

weixin_33708432的博客 183

倍福Beckhoff运动控制功能块实战解析:从MC_ReadActualPosition到MC_GearInVelo

本文深入解析倍福(Beckhoff)TwinCAT运动控制功能块,从基础的MC_ReadActualPosition、MC_Power等轴状态读取与使能操作,到MC_MoveAbsolute、MC_MoveRelative等单轴定位指令,并重点剖析了用于动态速度同步的核心功能块MC_GearInVelo在飞锯等场景的应用。文章结合实战经验,详细介绍了齿轮耦合、电子凸轮(MC_CamIn)等高级同步功能的参数配置、调试技巧及常见问题,旨在帮助工程师快速掌握倍福运动控制工具箱,实现复杂的同步工艺。

transformer2023的博客 981

C# 频繁操作string导致卡顿耗时长!StringBuilder解决问题!

未修改代码: Stopwatch stop = new Stopwatch();stop.Start(); string str = ""; foreach (var item in dicImage) { str += $"{item.Name}?"; foreach (var ty in item.Types) {

余道长的博客 980

【vLLM-性能洞察】基于Ascend Profiler的端到端推理瓶颈定位与优化实践

本文详细介绍了如何利用Ascend Profiler对vLLM-Ascend大模型推理服务进行端到端的性能瓶颈定位与优化。通过实战案例,阐述了从数据采集、可视化分析到诊断低效算子、内存管理、计算通信重叠及框架调度等常见瓶颈的全过程,为基于昇腾NPU的AI推理性能调优提供了系统性的方法论和实用工具指南。

cc789的博客 522

DELL SC存储扩容避坑指南:6Gb vs 12Gb扩展柜混插的真相

本文深入解析DELL SC存储扩容中6Gb与12Gb扩展柜混插的核心规则与性能影响。文章指出,从SCOS 7.3版本起允许混插,但整个SAS环路速率将降至最低设备水平,尤其在12Gb控制器上接入6Gb扩展柜会严重拖累性能。指南提供了清晰的兼容性矩阵、实战操作流程及关键避坑清单,帮助管理员安全、高效地完成存储扩容。

weixin_28314575的博客 459

c# sqlserver 删除大批量数据超时

我做的项目有个功能需要进行批量删除,删除的数据量有4.5W条数据。 通过下面的sql语句删除这么多数据,直接导致结果超时,无法删除数据。 DELETE FROM dbo.RRoleUser WHERE ID IN (1,3,4,5......) 我查了一些资料,可能找的不全,找到了一个方法,分批次删除,每次删除100条或者1000条…… 代码如下: ...

aex34027的博客 1703

从开通VPS到搭建宝塔面板全教程

你在输入域名(此时我们可能没有类似aaa.com这样的域名,所以要输入VPS的IP地址)的时候,下面的根目录也会跟着变动,等输入完成后,你可以把根目录再改回成/www/wwwroot/dq。这时,在你的浏览器中,输入外网面板地址的URL,输入username和password,即可登陆宝塔面板。第一次登陆,需要绑定你的宝塔账号,你可以到宝塔的注册界面,用手机注册一个,然后绑定,首先看一下你的VPS操作系统是什么类型的(其实你在选择VPS的时候,就已经选定了,我选择的事Centos系统)。

kxltsuperr的专栏 3734

C#确实是很“慢”——最后的疯狂

说真的,我也开始觉得大家认为“firelong是dudu请来的公关”这种理论是有道理的。因为这位英雄一开贴就炸出一个大坑,众多博客园中的老一辈已经出现了很多。这不,我宣布了无限期潜水都跳出来了,搬出去的Jeffrey也在这里面不停的回复。哈哈,知道我还看到了谁?装配脑袋哦!嗯,不知道接着灵感之源是否会出现。这真像是一个大狂欢啊!(怀念过去博客园那种讨论气氛。)不过我也确实感觉到:这会不会是博客园历...

weixin_34364135的博客 497

FreeRTOS OTA实战:从Bootloader设计到安全升级的完整流程(附MQTT示例代码)

本文详细介绍了在FreeRTOS系统中实现安全OTA固件升级的完整流程。内容涵盖从Bootloader设计、存储分区规划到与MQTT协议集成的OTA Agent任务开发,并重点解析了固件签名验证、防回滚等关键安全机制,为嵌入式物联网设备提供了一套高可靠性的远程升级解决方案。

weixin_29248653的博客 161

【HAL库】STM32CubeMX开发----STM32F407----ETH+LAN8720A+LWIP----ping通

本次实验以芯片为MCU,使用25MHz外部时钟源。以太网PHY层芯片为LAN8720A,由MCU引脚PA8提供时钟。

MQ0522的博客 4843

C#会重蹈覆辙吗?系列之1:论C#性能不能承受之慢

针对firelong在前贴《C与 C++社区混战,C#会重蹈覆辙吗?》http://www.cnblogs.com/firelong/archive/2010/06/20/1761357.html中 发布的博文,评论者众。似乎触动了.NET社区每个人的奶酪——我那么喜欢C#的那些特性,firelong凭什么指责它们,大呼小叫的屎盆子便扣将过 来。 Firelong既然写了帖子就有...

weixin_34067980的博客 512

Unreal5从入门到精通之如何实现移动端触屏滑动手势

随着移动设备的普及,越来越多的游戏和应用选择在移动平台上发布。Unreal Engine 5(UE5)作为一款强大的游戏引擎,提供了丰富的工具和功能,帮助开发者打造出色的移动体验。UE5不仅提升了图形质量,还大幅简化了开发流程,使得开发者能够更专注于游戏设计和用户体验。在移动游戏中,触屏滑动手势是用户与应用互动的主要方式之一。然而,许多开发者在实现这些功能时常常遇到困难。为了填补这一知识空白,本篇文章将详细介绍如何在UE5中实现移动端触屏滑动手势,帮助你从入门到精通,提升你的开发技能。

TxNet 1137
上一篇: C#常用开源项目
下一篇: 如何写健壮的代码
jackfirst86
博客等级 码龄18年 28粉丝 27原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值