vs.net 有没有插件可以在单步或者其他方式调试的时候显示代码行的执行时间？ 另外能手工控制GC回收机制么？

[boyyao]

程序对性能有要求。
单步调试看看时间花在那些语句上了。不知道有没有办法可以直观的知道那些语句/方法执行时花费了多少时间？？

另外请教下。GC对程序执行时间有影响么？我现在的情况是
正常情况下一个签名算法下来大概5ms左右。但是连续测试时发现。。有时候会突然飙升到几十毫秒（同样的输入输出）怀疑和GC有关。不知道怎么排查。。

[enaking]

Visual Studio 2015 默认就能显示时间。

[boyyao]

请问哪里显示？是我设置不对么？我是vs 2019 。是精确到 代码行的么？还是精确到函数？

[wanghui0380]

为啥你们第一件是就是学博客园的，“你离高手就差一个GC”，博客园典型的就是先忽悠瘸，然后卖拐。 我想问的事情是，gc管的是什么？gc管内存，so，你说我觉着几十毫秒慢了，你会去怪内存？是因为多分配内存了，所以cpu就慢了？ 这是个什么逻辑来着，明显是忽悠瘸，然后递拐么 慢了，是因为cpu调度慢了，你说签名算法对吧，我们说这是需要计算的事情，归cpu管，你慢是cpu算慢了，不是内存慢了，为啥cpu调度慢了，那是因为需要执行的东西多了。cpu采用时间片调度轮询，当你加入的东西多了，他就只能这个干几纳秒，那个干个几纳秒。 所以你想快，不要管内存。请先看你有多少并发线程，而不是先找gc背锅

[wanghui0380]

顺带说一句，博客园长期把锅丢给gc，丢给内存，丢给string，如果说问题是内存溢出，内存爆掉，你去找gc可以 其他事情，先找别的问题。 一大堆文章都是，我慢，微软的错，gc的错。煞有介事的弄个dump，玩个windbg，貌似高手的分析来，分析去，结果说你看这个string 占了200M就是他，就是他 我们说这是结果，不是原因。真正的原因是，你慢，所以你的方法或线程没有退出，堆积在那里，所以那个string还在用，所以gc还木有给你释放，这是你慢造成的结果，不是因为string堆积造成了你慢。这个锅gc和string都不该背

[wanghui0380]

至于内存对程序性能的影响，内存属于io部分，大内存好处是允许把更多的数据放入内存，这样比访问磁盘io快 1.当无法分配内存时（大多数情况到不是内存不够，而是碎片过多，无法分配你需要的连续内存），会异常。这与慢无关，到会引发程序整体崩溃，造成服务失败，引发其他服务的问题。 2.当物理内存不足 ，系统会把数据放入虚拟内存，这种情况下到可以说引发你慢，因为虚拟内存在磁盘上，磁盘IO是要比物理内存慢。但是系统做法是你物理内存不够才会做这件事情，所以问题回到最初。何种情况下我们才会把物理内存用到必须使用虚拟内存的地步？还是因为算的慢啊

[boyyao]

感谢耐心解答。。使得我重点不去排除GC问题。现在基本确定是因为类似签名等算法是计算密集型。在多线程下可能是线程调度（只是并发，没有并行）问题（猜测和py等一样的多线程机制，我用TASK来开多个签名任务同时执行） 。 我尝试多线程同时签名多个消息 执行的总时间往往比单个逐个执行还要久。。。 我开了另外一个帖子。想请教一下假设我想实现“多线程”“并行”来同时处理多个签名。是需要多进程去处理。还是能有什么方法使得线程真正的并行运行？

[weixin_47006459]

引用 6 楼 boyyao 的回复:

感谢耐心解答。。使得我重点不去排除GC问题。现在基本确定是因为类似签名等算法是计算密集型。在多线程下可能是线程调度（只是并发，没有并行）问题（猜测和py等一样的多线程机制，我用TASK来开多个签名任务同时执行） 。 我尝试多线程同时签名多个消息 执行的总时间往往比单个逐个执行还要久。。。 我开了另外一个帖子。想请教一下假设我想实现“多线程”“并行”来同时处理多个签名。是需要多进程去处理。还是能有什么方法使得线程真正的并行运行？

这个貌似要看你CPU是几个核吧，你开太多线程，他核不够其实还是要等待的吧