呵呵~~~见原贴 
http://expert.csdn.net/Expert/topic/2561/2561076.xml?temp=.8762476

解决方案 »

  1.   

    FileStream已经包含了文件缓冲,不需要设置BufferedStream。我读取小于10M的文件时都是很快的,你可以在构造FileStream时更改缓冲区大小(好象是1-8的数字),我是设置为2。当然如果文件太大,你可以异步读取(FileStream本身集成了这些功能)BTW,一般只有NetworkStream才需要设置缓冲区希望能对你有所帮助~~~这是楼上的回复.
    请问楼上怎么样缓冲区大小?
      

  2.   

    这个问题很复杂。
    首先,你在IDE中按F5运行程序(就是debug模式),程序运行后,你观察output窗口(如果没有,按Ctrl+Alt+O)。到运行得很慢的代码的地方,你看看,是否有这样的信息输出:***** loaded 'path\assmeblyname.dll' , symbols loaded。有一种情况,是因为jit的时候,你需要的assembly刚刚被load出来(途径可能不一样:gac、cache、codebase)。比如所,xml.dll这时候被load进来,速度很慢。
    如果你是直接按F5运行的,那么这时候的代码是没有被优化的。如果按Ctrl+F5或者在explorer中double click运行的,这时候“可能”是被优化的(和你的project的设置相关)。如果被优化了,速度会快一些。
    其次,打开performance monitor,监视所有的elements,(新建一个performance counters log),然后结合adplus.vbs来抓这些信息。(这是微软解决这类问题的标准作法)自己来分析里面的数据(一般用cordbg来作)。或者,你用这段代码放到你的程序中:
    System.AppDomain app = System.AppDomain.CurrentDomain;
    app.AssemblyLoad += new AssemblyLoadEventHandler(OnAssemblyLoad);
    app.AssemblyResolve += new ResolveEventHandler(OnAssemblyResolve);
    app.DomainUnload += new EventHandler(OnDomainUnload);
    app.ProcessExit += new EventHandler(OnProcessExit);
    app.ResourceResolve += new ResolveEventHandler(OnResourceResolve);
    app.TypeResolve += new ResolveEventHandler(OnTypeResolve);
    app.UnhandledException += new UnhandledExceptionEventHandler(OnUnhandleException);里面的handler你自己简单的写一些trace就可以了。性能调试与优化是个很复杂的过程,需要结合很多经验和方法来作,没有什么万能的做法。
      

  3.   

    简单的避免你的问题,可以开另外一个thread,把new instance的过程放到里面,然后用一个进度条之类的UI来缓和界面无相应的问题。
      

  4.   

    对了,对于我上面写的观察output中debug的信息,如果是某个.net framework的dll被load的时候慢,这是你可以把你的application deploy到其他人的机器上,看看是否还有这个问题?
    值得注意的是,如果你是用SmartClient方式或者远程运行winform的方式,杀毒软件对于assembly的检测,是非常耗费时间的。你可以把杀毒软件暂停(停止所有的service、app),然后看看效果怎么样?
      

  5.   

    正如juqiang(方枪枪(正在修炼伤心小箭)) 大虾所说的那样,我的程序的确是执行了以下的过程:
    “HDIViewer.exe”: 已加载“c:\winnt\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml.dll”,未加载符号。
    “HDIViewer.exe”: 已加载“c:\winnt\assembly\gac\mscorlib.resources\1.0.5000.0_zh-chs_b77a5c561934e089\mscorlib.resources.dll”,未加载符号。我在初始化form的时候,执行
    Parser parser = new Parser();
    使这些过程提前了,在后来再打开文件的时候,速度快多了如果只是这个原因,是不是意味着没有提高速度的可能性了?除了升级硬件之外。
      

  6.   


    TO ondelettes(小强) ( ):其实在调试进入这个类之前慢,主要是因为CLR在为对象分配内存。也就是说在对象的初始化时,第一步是执行new请求内存(所以会慢),然后会执行构造函数去初始化请求的内存区域完成对象的初始化动作并返回对象。====================================你说:
    我在初始化form的时候,执行
    Parser parser = new Parser();
    使这些过程提前了,在后来再打开文件的时候,速度快多了
    =====================================
    你的速度快多了,其实只是因为你提前完成初始化对象的动作(实际上并没有节约那点时间,只不过把初始化的动作提前罢了) 一个例子:
    Public class A
    {
    private ArrayList a;
    private ArrayList b=new ArrayList();//这里会慢 ,不过这点时间算到了A的初始化时间里了
    public void CreateInstance()
    {
       this.a=new ArrayList();//这里也会慢,你可以通过单步调试来检测(只要你的Class足够大)
    }
    }你可以看到,你所谓的放到初始化Form里执行并不能解决你的问题。个人认为还是你的FileStream用的有问题~~~BufferedStream本身是比较耗费资源的TO 方兄:
    我想这个应该和Assembly、IDE没有什么关系吧?才500K的文件  :)
    个人见解,还请斧正~~~
      

  7.   

    to  qimini(循序渐进) ( ),
    我也知道我的做法并不能从根本上解决问题,我仅仅是想做个试验,而且,这个做法跟之前提过的另开一个线程的方法一样,都是利用了其他的时间来完成这个工作。
    在您的帖子里提到:
    你可以看到,你所谓的放到初始化Form里执行并不能解决你的问题。个人认为还是你的FileStream用的有问题~~~BufferedStream本身是比较耗费资源的
    这样子的话,能不能给我一点进一步的建议呢?我希望通过BinaryReader来分析文件的内容
    还有一点疑惑的是,我运行以下语句:
    ins = new BufferedStream(new FileStream(ofdlg.FileName, FileMode.Open, FileAccess.Read));
    运行速度并不慢的最后补充一下实际情况。在我没有任何修改之前,打开第一个文件的时候(主要是指第一次实例化),大概需要四五秒。之后再打开文件就好多了,没有太明显的停滞。不过,我想也是因为我并没有分配更多的资源的缘故,每次打开文件的操作都是一样的。另外,我在电脑上安装了许多系统级别的服务,一般来说执行速度都会慢一些。如果是
      

  8.   

    嗯,我尝试了以下的语句,省掉了BufferedStream的过程
    parser = new FileParser(new FileStream(ofdlg.FileName, FileMode.Open, FileAccess.Read))
    结果真的快了好些,没有明显的停滞了
      

  9.   

    第一次慢是因为JIT的原因,需要编译(在调用对象的第一个方法时)。而以后运行CLR会自动运行已经编译的版本,这样速度会快很多---除非你更改了源代码或者从IDE再次编译
      

  10.   

    to qimini,和assembly是相关的。因为速度慢有一部分因素,是因为.net自己的system.dll/xml.dll等都需要load进来。如果在debug模式下,还需要load symbols,这也是耗费时间的。to 小强,qimini讲的对,第一次需要jit,所以比较慢。你可以打开taskmgr.exe,注意看里面的进程,你的程序load的时候,会先有一个csc.exe在运行,这就是在编译。这个csc的过程,可能要出来好几次。