当然,很多事物和方法的存在有它的存在理由;而本贴,只从系统的性能优化方面考虑,寻求更优秀的编程技巧.
本人知识非常有限,只能举简单的例子,抛砖引玉;
为方便以后分类整理,大家查找方便,建议用固定格式: 如,//数据库相关:
1.把sql语句写在存储过程里,优于写在程序文件里;
    //理由:XXXX
2.XXXXX
.
.
.
//算法相关:
1.XXXXX
    //理由:XXXX
.
.
.
//控件相关:
1.用XXX控件的XX1方法比它的XX2方法好;
    //理由:
.
.
.
.

解决方案 »

  1.   

    //文件目录创建相关
    1.对于上传/下载目录,尽量生成多个文件夹,即使每个文件夹放最可能少的东西;
        //理由:系统可以不理会另的同目录下的文件夹,而快速直接通过详细路径如\aa\a1\a11\访问最下层文件夹,再扫描查找目的文件夹里面的文件;
      

  2.   

    //页面设计应用相关
    1.应该尽可能少地使用用户控件,特别是与具体应用相关的包括了一大部分TextBox等的控件
      //理由:具体到应用,需求和改进随时都会对部分页面提出修改,使用了自定义控件的页面很难修改,当然,可能是我还没学到家
      

  3.   

    搞了一年半的。net  就学会一个三层/多层架构。知道把功能分开写。
    同时也觉得按照这样的代码写起来,代码量还是挺大的。    有点感觉:中间逻辑层,如果是大型的项目,就要有专门的逻辑层,针对划分的每个对象的逻辑都放在逻辑层中。如果是中小型的项目,建议逻辑层是针对页面(表示层)来划分,这样用起来会更方便。
      

  4.   

    //数据集,数据表相关
    1.尽量用Tables[index] 代替其它获取Table的方式
        //理由:相对于其它方式,如Tables["TableName"],Tables[index]比它高效达6倍或更多.
    2.请在这些情况下使用DataSet,当数据需要不时更改,变化,又需要及时更新到显示层时.
        //理由:这是针对很多不想用DataSet的"高手"的建议,数据集的底层的服务,和数据处理机制相对于一个研究不深的生手来说是优化得多的.??不敢确定,也要说了.
      

  5.   

    现在编程不是特别讲究性能,如果能够增加内存或服务器能使性能上去,就是好的程序.
    一般提高性能的模式有:延迟加载,缓存等.
    如将SQL写在PROC里本人就不是特别赞成,可读性不太好,个人觉得设计时不应过度考虑性能问题,尤其是根本没这个需要时,有时候程序员太喜欢追求完美不是个很好的习惯.
      

  6.   

    //循环,集合,迭代相关
    1.用 int count = items.Length  for(int i=0;i< count;i++){} 代替 for(int i=0;i<items.Length;i++){}
        //相信大家都知道为什么,但我不敢保证是每个人都记得这样用.
      

  7.   

    Mark,新人,知道的不多,慢慢看
      

  8.   

    性能最优的往往不是最好的,编程的终极目标是在 速度,效率,成本,可维护性,等各个方面达到一个最佳平衡而不是仅仅是性能最优,只有结合特定问题,讨论性能最优才是有意义的,编程没有定律所以象这种 "1.把sql语句写在存储过程里,优于写在程序文件里;"根本就没有必要讨论,因为肯定有不适用的情况
      

  9.   

    dataset有很多机制可以减少和数据库的交互,用好了会大大提高运行速度。比如Tables的Compute,Select等方法
      

  10.   

    只能考虑性能优化下的编程技巧,似乎容易引入另一个怪圈。事实上在大部分设计中,我们都是在 时间、空间与简便之间寻找一个平衡。至于真的需要去苛求算法的情况还是少数。而大部分时间,我们还是会牺牲时间来换取简单,或是牺牲空间来换取方便,或者是牺牲时间来换取空间,或牺牲空间来换取时间。当然还有很多其他的考量。象楼主所提的把SQL语句放在存储过程中,肯定被很多SA给枪毙,因为从分层设计的模式中,数据层与逻辑层是应该分开的。其实在大部分情况下,只有Server端的应用才真的需要调优,一般Client的应用需求比较少。(我这里指的Client与Server并非传统的 C/S结构中的,而是指客户端与服务应用端)。因Client的应用通常时间的要求不高,这样你就没必要为了把时间从0.1秒提高到0.001秒去花太多的心思。而Server端的调优,你很难说哪种算法比较好,哪种方法比较好用,因为这都是Case by Case,没有统一的标准。个人意见,以免大家为了速度而速度。有一句话说得很好,Simple is the best .
      

  11.   

    to mba9001(青春存折)
    “1.尽量用Tables[index] 代替其它获取Table的方式
        //理由:相对于其它方式,如Tables["TableName"],Tables[index]比它高效达6倍或更多.”
    这种方式对代码的可读性和维护没有任何好处。
    to gzlucky(Lucky) 
    同意你的意见。
      

  12.   

    //数据库相关
    如果使用XML数据库,尽量使用多个XML文件存放不同类别。如果是全部Load进来查询的话,最好在插入的时候就将数据排好序,查询的时候可以用二分法等算法。
    当然如果追求内存要求的话,可以使用不加载所有节点,而是动态的推进。
      

  13.   

    数据库相关:
    1 LIKE  ABC%   比  SUBSTR(0,3)=ABC  这种要快的多2 TOP 5 *  ...WHERE ID>30 ORDER BY ID 比
    ..... WHERE ID >30 AND ID <35  要快3 NOT LIKE 在数据量大的时候,对效率影像很大4 指明多表关系会大大提高速度 ,如
    SELECT A.X,B.Y FROM A B WHERE A.X=B.X
    SELECT A.X,B.Y FROM A INNER JOIN B ON A.X=B.X
    2句结果一样,但是速度相差很多,时间复杂度分别是 O(2n)和O(n*n)
    类C语言代码相关(C/C++/C#/Java等)
    i++速度高于  i=i+1和i+=1   后2者只是写法不同,效率一样.
    (A)?B:C  速度忧于  if(A){B}else{C}  在C和C++中区别比较大,C#中仅仅是IL语句少小点而已.
    其他:
    仅仅分层会降低执行性能,但是分层而允许分布部署则可以大大提高执行能力.
    千方百计降低算法的时间复杂度和空间复杂度是根本的优化方法.
    一时想不起太多了.....这是个经验问题和习惯问题.做到了就记起了,突然要说也说不上太多.
    最后.........其实现在执行效率稍微注意一下也就够了,在大部分情况下,追求效率的极致会损失代码可读性和其他一些东西,关键是寻找一个"平衡点"而不是追求"最快".否则,你选择C#选择.Net就已经是个错误决定了.
      

  14.   

    补充,突然想起.类C语言代码相关(C/C++/C#/Java等)
    i++速度高于  i=i+1和i+=1   后2者只是写法不同,效率一样.
    (A)?B:C  速度忧于  if(A){B}else{C}  在C和C++中区别比较大,C#中仅仅是IL语句少小点而已.+这个:
    A<<N   和A>>N 的速度远高于A*POW(2,N)和A*POW(2,0-N)
    尽量在大数的算数运算中把高复杂运算(比如除法)通过一些数学手段变成低复杂度运算(比如加法)
      

  15.   

    to mba9001(青春存折)
    “1.尽量用Tables[index] 代替其它获取Table的方式
        //理由:相对于其它方式,如Tables["TableName"],Tables[index]比它高效达6倍或更多.”
    这种方式对代码的可读性和维护没有任何好处。
    to gzlucky(Lucky) 
    同意你的意见。const int users = 0;
    Tables[users]
      

  16.   

    执行时间 
    处理一个请求所需的时间,通常按服务器向客户端返回的第一个字节和最后一个字节之间的时间计算。执行时间直接影响吞吐量的计算。 
    响应时间 
    从提出请求到服务器将第一个字节返回客户端之间的时间长度。对于客户端用户,这通常是性能中最直观的一个方面。如果应用程序响应时间很长,用户可能会觉得不耐烦,并转到另一个站点。应用程序的响应时间的改变与吞吐量的速率无关(甚至成反比)。 
    可伸缩性 
    用于衡量应用程序在获取更多资源(内存、处理器或计算机)时更好地执行的能力。它经常按吞吐量相对于处理器数的更改速率计算。 
    吞吐量 
    Web 应用程序在单位时间之内可以处理的请求数,经常以每秒请求数衡量。吞吐量可根据应用于服务器的加载(客户端线程数)而不同。这通常被视为要优化的最重要的性能度量。 
      

  17.   

    下面的指南列出特定的技术,您可以使用这些技术确保所编写的代码达到可接受的性能级别。 当不使用会话状态时禁用它。并不是所有的应用程序或页都需要针对于具体用户的会话状态,您应该对任何不需要会话状态的应用程序或页禁用会话状态。 
    若要禁用页的会话状态,请将 @ Page 指令中的 EnableSessionState 属性设置为 false。例如,<%@ Page EnableSessionState="false" %>。 注意   如果页需要访问会话变量,但不打算创建或修改它们,则将 @ Page 指令中的 EnableSessionState 属性设置为 ReadOnly。
    还可以禁用 XML Web services 方法的会话状态。有关更多信息,请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services。 若要禁用应用程序的会话状态,请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off。例如,<sessionstate mode="off" />。 仔细选择会话状态提供程序。ASP.NET 为存储应用程序的会话数据提供了三种不同的方法:进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点,但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据,则建议您使用进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序,或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息,请参见 ASP.NET 状态管理。 
    避免到服务器的不必要的往返过程。虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能,但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。 
    通常,只有在检索或存储数据时,您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如,从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常,如果不需要将信息传递到服务器以将其存储在数据库中,那么您不应该编写导致往返过程的代码。 如果您开发自定义服务器控件,请考虑让它们为支持 ECMAScript 的浏览器呈现客户端代码。通过以这种方式使用服务器控件,您可以显著地减少信息被不必要的发送到 Web 服务器的次数。有关更多信息,请参见开发 ASP.NET 服务器控件。 使用 Page.IsPostBack 避免对往返过程执行不必要的处理。如果您编写处理服务器控件回发处理的代码,有时可能需要在首次请求页时执行其他代码,而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的,使用 Page.IsPostBack 属性有条件地执行代码。例如,下面的代码演示如何创建数据库连接和命令,该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。
      

  18.   

    详情可见:
    ms-help://MS.NETFrameworkSDKv1.1.CHS/cpguidenf/html/cpcondevelopinghigh-performanceaspnetapplications.htm
      

  19.   

    不能让这样的贴子沉了。顶
    ================================================================
    此帖通过csdn小助手回复。
        CSDN小助手是使用vb.net(开源)编写的CSDN论坛脱机“外挂”,她能够在
    脱离IE的情况下使用Csdn论坛。程序只加载最核心的数据,所以显示更
    快,产生的流量更小。    下载地址:http://qqwwee.com/csdn.rar
    ================================================================
      

  20.   

    说实话,这些平时都没怎么考虑,就考虑实现了,
    这么一研究感觉有意思多了!呵~~~
    好东西,MARK!
      

  21.   

    数据库相关利用DataSet分页显示数据:System.Data.OLeDb.OleDbCommand odcd;
    System.Data.OleDb.OleDbDataAdapter  odda;
    System.Data.DataSet Ds;//数据库连接等略,取数据集略//一般数据分页显示填充办法
    odda.Fill(Ds,开始号,填充大小,"数据表");
    //显示数据
    foreach(System.Data.DataRow dr in Ds.Tables["数据表"].Rows)
    { dr["字段名"];}//高效能语句
    for(i=0;i<Ds.Tables["数据表"].Rows.Count;i++)
    {Ds.Tables["数据表"].Rows[i]["字段名"];}//完整可参考
    odda.Fill(Ds,"数据表");
    for(int i=开始号*填充大小,j=0;i<Ds.Tables["数据表"].Rows.Count&&j<填充大小;i++,j++)
    {Ds.Tables["数据表"].Rows[i]["字段名"];}理由:
    odda本来就已经将数据集缓存带内存中,却要有选择将其中数据拷贝到Ds对象,其实这一点综合来看性能影响不大.
    关键是后面,foreach语句很影响性能,如果能避免最好不用,利用索引尤其是数字索引对象效率非常高,速度很快
      

  22.   

    类C语言代码相关(C/C++/C#/Java等)
    i++速度高于  i=i+1和i+=1   后2者只是写法不同,效率一样.
    (A)?B:C  速度忧于  if(A){B}else{C}  在C和C++中区别比较大,C#中仅仅是IL语句少小点而已.精妙,的确,C#,现在的编译器,生成的代码一样的!!