因为处理bug、崩溃、调优、入侵等突发事宜比编程本身更能表现平淡法度榜样员与幻设法主意度榜样员的差距。当面对一个未知的问题时，若何定位复杂前提下的核心问题、若何抽丝剥茧地分析问题的潜在原因、若何清除干扰还原一个最小的可验证场景、若何抓住关键数据验证本身的猜测与实验，都是表现法度榜样员思虑力的最好场景。是的，在衡量幻设法主意度榜样员的标准上，思虑力比经验加倍重要。

此次我选用的时VS自带的Performance Profiler，开辟情况下极其强大年夜的机能调优对象。针对我们当前案例，我们仅须要跟踪指定办事对应的dll即可，应用步调如下：

Analyze-->Profiler-->New Performance Session
打开Performance Explorer
找到新添加的Performance Session，右键Targets，然后选择Add Target Binary，添加要跟踪的dll文件即可
将应用跑起来
选中Performance Session，右键Attach对应过程即可跟踪分析机能了
在跟踪过程中，可随时暂停跟踪和停止跟踪

跟踪停止后本案例跟踪到的采样结不雅如下图：

同时Performance Profiler也给出了问题的建议，如下图：

个中第1、4条大年夜致解释法度榜样I/O消费大年夜，第一代的GC上存在未及时释放的垃圾占比过高。而根据上图的采样结不雅，我们可以直接看出是因为再代码中频繁操作DataTable引起的机能瓶颈。走读代码发明切实其实如斯，所有的数量统计都是在代码中轮回遍历DataTable进行处理的。而最终的优化策略，就相当于一次大年夜的重构，将所有代码中经由过程遍历DataTable的计算逻辑全部挪到SQL中去做。因为代码过多，就不再放出。

案例3：客户反馈批量惹人1000张订单，耗时40mins左右，且轻易中断。

同样，我们照样先测验测验本地重写。经测试批量惹人101张单据，就耗时5mins阁下。下一步打开Sql监控对象也未发明耗时语句。但推敲到是批量导入操作，固然单个耗时不多，但乘以100这个基数，就明显了。下面我们就应用RedGate的Ants Performance Profiler跟踪一下。

该对象比较直不雅，可以同时监控代码和SQL履行情况。第一步，New Profiler Session，第二步进行设置，如下图。根据本身的应用法度榜样类别，选择响应的跟踪方法。

针对这个问题，我们跟踪到的调用客栈和SQL耗时结不雅如下图：

所以，若你不甘平淡，请拥抱机能调优的每一个机会。当你拥有一个精确的心态，你所面对的机能问题就已经解决了一半。

3. 再说技能

起首大年夜调用客栈中的Hit Count，我们可以起首看出它是一个批量过程，因为人口函数仅调用一次；第二个我们可以代码中是轮回处理每一个单据，因为Hit Count与我们批量惹人的单据数量相符；第三个，忽然来了个10201，如不雅有必定的数字敏感性的话，此次机能问题的原因就被你找到了。这里就不卖关子了，101 x 101 = 10201。
是不是明白了什么，存在轮回嵌套轮回的情况。我们走读代码肯定一下：

//Save.cspublic override void EndOperationTransaction(EndOperationTransactionArgs e) {    //省略其他代码    foreach(DynamicObject dyItem in e.DataEntitys) {        //反写收款单        WriteBackReceiveBill wb = new WriteBackReceiveBill();        wb.WriteBackForSave(e, this.Context);    }}//WriteBackReceiveBill .cspublic void WriteBackForSave(EndOperationTransactionArgs e, Context contx) {    //省略其他代码：    foreach(DynamicObject item in e.DataEntitys) {        //do something     }}

好嘛，外层套了一个空轮回却什么也没做。修改就很简单了，删除无效外财揭捉?环即可。