zoukankan      html  css  js  c++  java
  • 性能杀手之异常霸气外露!找死!

    在上篇:周末浅说--未将对象引用设置到对象的实例(System.NullReferenceException) 中,介绍了一个比较经典的异常。

     

    文中并浅出一些个人观点,又潜伏一些观点。

    本节将从上篇的文章中,引申潜伏在上文的另一个主题异常霸气外露!找死!

    先不说网友以前是怎么认识try catch和异常的处理,这里先给出两个示例代码:

    1:循环20万次的判断,看时间:

     

            static object a;
            
    static void Main(string[] args)
            {
                System.Diagnostics.Stopwatch watch 
    = new System.Diagnostics.Stopwatch();
                watch.Start();
                
    for (int i = 0; i < 200000; i++)
                {
                    
    try
                    {
                        
    if (a != null)
                        {
                            a.ToString();
                        }
                    }
                    
    catch
                    { }
                }
                watch.Stop();
                System.Console.WriteLine(watch.ElapsedMilliseconds);
                Console.Read();
                }

    本机的结论是:0毫秒

    这里只是想最直白的说明一下:加一个判断,并不影响性能。

    2:循环1次,抛异常并捕获

            static object a;
            
    static void Main(string[] args)
            {
                System.Diagnostics.Stopwatch watch 
    = new System.Diagnostics.Stopwatch();
                watch.Start();
                
    for (int i = 0; i < 1; i++)
                {
                    
    try
                    {
                        
    //if (a != null)
                        
    //{
                            a.ToString();
                        
    //}
                       
                    }
                    
    catch
                    {
     
                    }
                }
                watch.Stop();
                System.Console.WriteLine(watch.ElapsedMilliseconds);
                Console.Read();

    本机的结论是:2毫秒

    这里只是想最直白的说明一下:1个异常的抛出的时间,能挡住60万次的判断。

    这个结论同时表明:加判断,并不是不重视性能,反而正是性能最直白的体现。

    在个人的印象中,前人就有文章指出异常对性能的影响,当然这个可能年代太久了,大伙没啥印象了。

    今天本人只是换个角度,换个方式,去传达这么一种理念:异常应该避免,而不是捕获,捕获,那是不得已而为之。

    这里再顺路推出微软一个让人纠心的未处理的异常:Dictionary<T,T>的Add方法:

    if (!dic.ContainsKey(key))
    {
       
    try
        {
            dic.Add(key, info);
        }
        
    catch
        {
        
    //反编绎微软内部调用:private void Insert(TKey key, TValue value, bool add) 可能会抛异常:Index was outside the bounds of the array
        }
    }

    正常的写法,是不用加try catch,可是微软也不是百分百完美的,就像我下面注释的异常,有一定的小概率会抛异常出来,不得已捕获之。

    好,懂事的看完上面的内容,基本都明白事理了,下面再扯几句给不怎么懂事的清闲清闲:

    霸气外露!找死!-- 这是发哥在让子弹飞的话,今天借来一用!

    这里从两个角度上发挥一下:

    1:假设我们很注重性能

    假充我们很注重性能:现在我们明白了,一个异常不经易的抛出,就害我们损失了60万次的判断,唉哟妈喂,这得吓死多少千年虫!

    以前常整天忙碌在用S好还是用B好,精心设计来设计去,减少来减少去,折腾来折腾去还不一定有60万这么大数字,现在一看,蒙了!

    原来家里还有这么一只超级大老鼠,整天吃性能,以前竟然没发现!!!不过今天。。。

    异常霸气外露!找死!

     

    霸气外露,遇到我们这群性能执法者,纯找死!得把你给灭了,灭一个就是省60万,灭两个就是省120万,灭多几个,房子车子全有着落了!

    2:假我们不是很关注性能

    假设我们不是很关注性能:一个异常2毫秒,多大点屁事,60万次判断?你家的啥CPU?没个上百次你都不好意思上来说了。


    反正秒级以下的都问题不大:抛500个异常也无所谓了,就一两秒的时间。


    G要的是稳定,稳定!!!明了?
     

    不过话说回来,虽然不在乎点时间,可是这。。。

    异常霸气外露!找死!

    我们领导最恨的就是异常,还霸气外露,露多几下G这饭碗还能握的住么?不行,不管什么异常,得坚决的消灭,消灭不掉的,得藏起来,坚决不能让它外露!

    这不,那个车头不就是霸气外露,才被埋的么!!! 

    顺路PS: CYQ.Data V4.5离线帮助文档,很快发布,敬请关注。

  • 相关阅读:
    非系统表空间损坏,rman备份恢复
    非系统数据文件损坏,rman备份恢复
    开启 控制文件自动备份下,参数文件、控制文件全部丢失恢复
    rman命令详解(三)
    Block Change Tracking (块改变跟踪)
    如何加快建 index 索引 的时间
    RMAN兼容性、控制文件自动备份、保存时间、备份策略、备份脚本(二)
    rman理论(一)
    动态参数与静态参数的判断、修改
    闪回之 Flashback Data Archive
  • 原文地址:https://www.cnblogs.com/cyq1162/p/2116070.html
Copyright © 2011-2022 走看看