【问题标题】:C# performance questionC# 性能问题
【发布时间】:2010-12-04 03:13:47
【问题描述】:

qudry 是 - 以下两种方法中哪一种效果最好
目标 - 获取 Wrapper 类型的对象(定义如下)
标准 - 存储速度
不。记录 - 大约 1000 - 大约 2000,最大大约 6K
选择 - 动态创建对象或从字典中查找
执行速度 - 每秒调用 x 次

注意 - 我需要先交付工作代码,然后再进行优化,因此如果任何理论家可以提供幕后信息的一瞥,这将有助于在我可能通过 eod thu 进行实际性能测试之前提供帮助

定义-

class Wrapper  
{  
   public readonly DataRow Row;  
   public Wrapper(DataRow dr)  
   {  
      Row = dr;  
   }  
   public string ID { get { return Row["id"].ToString(); } }  
   public string ID2 { get { return Row["id2"].ToString(); } }  
   public string ID3 { get { return Row["id3"].ToString(); } }  
   public double Dbl1 { get { return (double)Row["dbl1"]; } }  
   // ... total about 12 such fields !  
}  
Dictionary<string,Wrapper> dictWrappers;  

方法一

Wrapper o = new Wrapper(dr);  
/// some action with o
myMethod( o );

方法二

Wrapper o;    
if ( ! dictWrappers.TryGetValue( dr["id"].ToString(), out o ) )    
{    
    o = new Wrapper(dr);    
    dictWrapper.Add(o.ID, o);    
}    

/// some action with o    
myMethod( o );    

【问题讨论】:

  • 您的问题是什么?如果您想知道哪个运行最好,请查看 System.Diagnostics.Stopwatch,并为大量运行计时。
  • 嗯...你为什么不自己测试一下呢? -1
  • 嗯,再读一遍这个问题——它清楚地说明了在我自己进行实际基准测试之前是否有任何理论家可以提供有关发生了什么的一瞥

标签: c# .net performance optimization high-availability


【解决方案1】:
  1. 不先进行分析,切勿优化。
  2. 除非代码不符合规范/预期,否则切勿配置文件。
  3. 如果您需要分析此代码,请以两种方式编写它并使用您的预期负载对其进行基准测试。

编辑:除非性能不可接受,否则我尝试支持以下优化:

  • 简单
  • 可读性
  • 可维护性
  • 可测试性

我(最近)看到了非常难以调试的高度优化的代码。我对其进行了重构以简化它,然后进行了性能测试。性能是不可接受的,所以我对其进行了分析,找到了瓶颈,并且只优化了那些。我重新运行了性能测试,新代码与高度优化的版本相当。而且现在更容易维护。

【讨论】:

  • & 因此上面的 Note Bene (NB)
  • @Kumar:如果我说我是专家并且方法 2 更快,你会相信我吗?唯一确定的方法是对其进行基准测试。即使那样,问题是它是否会对您的情况产生重大影响。我会选择一个,交付代码,运行性能测试,只有当它不符合规范时,我才会分析代码。
  • 公平地说,我不相信你的表面价值,但就像上面指出的那样,我想知道更多关于什么和为什么而不是 IJWTW(它只是这样工作)或一些这样,我最终会在几天后再次进行分析,如上所述
【解决方案2】:

这是一个免费的profiling tool

【讨论】:

  • +1 - 这是我使用的那个;这是基本的,但价格合适。
【解决方案3】:

第一个会更快,因为它实际上并没有进行查找,它只是进行简单的分配和赋值。

这两段代码几乎不等价。但是在功能上,因为方法 1 可能会创建许多重复项。

【讨论】:

    【解决方案4】:

    如果不进行实际测试,我希望在 Wrapper 中缓存字段值(即避免所有 ToString 调用和强制转换)可能会对性能产生更大的影响。

    然后,一旦您缓存了这些值,您可能希望保留 Wrapper 的实例,而不是频繁地重新创建它们。

    【讨论】:

    • 好主意,但它只适用于 5-6 个字段/属性,其余的非常不稳定
    【解决方案5】:

    假设您真的担心 per(嘿,它确实发生了),那么您的底层包装器本身可以得到改进。您正在按字符串进行字段查找。如果您要在行中设置相同的字段进行大量调用,则缓存序号并按序号查找实际上更快。

    当然,这只是在您真的非常需要担心性能的情况下,而这会产生影响的情况相当少见(尽管在嵌入式设备中并不像在桌面设备上那么罕见)。

    【讨论】:

    • 是的,性能是关键,正常情况下至少每秒几百次
    猜你喜欢
    • 2011-04-16
    • 2012-07-01
    • 1970-01-01
    • 2012-06-05
    • 2014-09-14
    • 2011-06-30
    • 2023-03-12
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多