C# 性能问题

发布于 2024-08-06 16:32:53 字数 1130 浏览 2 评论 0原文

困惑是 - 以下两种方法中哪一种效果最好
目标 - 获取 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;  

方法 1

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

方法 2

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 );    

quandry is - which of the following two method performs best
Goal - get an object of type Wrapper ( defined below )
criteria - speed over storage
no. of records - about 1000- about 2000, max about 6K
Choices - Create Object on the fly or do a lookup from a dictionary
Execution speed - called x times per second

NB - i need to deliver the working code first and then go for optimization hence if any theorists can provide glimpses on behind the scene info, that'll help before i get to the actual performance test possibly by eod thu

Definitions -

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;  

Method 1

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

Method 2

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 );    

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

琉璃繁缕 2024-08-13 16:32:53
  1. 切勿在未先进行分析的情况下进行优化。
  2. 除非代码不符合规范/期望,否则切勿进行分析。
  3. 如果您需要分析此代码,请以两种方式编写并根据您的预期负载对其进行基准测试。

编辑:除非性能不可接受,否则我尝试优先考虑以下内容:

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

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

  1. Never optimize without profiling first.
  2. Never profile unless the code does not meet specifications/expectations.
  3. If you need to profile this code, write it both ways and benchmark it with your expected load.

EDIT: I try to favor the following over optimization unless performance is unacceptable:

  • Simplicity
  • Readability
  • Maintainability
  • Testability

I've (recently) seen highly-optimized code that was very difficult to debug. I refactored it to simplify it, then ran performance tests. The performance was unacceptable, so I profiled it, found the bottlenecks, and optimized only those. I re-ran the performance tests, and the new code was comparable to the highly-optimized version. And it's now much easier to maintain.

请帮我爱他 2024-08-13 16:32:53

这是一个免费的分析工具

Here's a free profiling tool.

梦言归人 2024-08-13 16:32:53

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

这两段代码并不几乎等同。然而,在函数中,因为方法 1 可能会创建许多重复项。

The first one would be faster, since it isn't actually doing a lookup, it is just doing a simple allocation and an assignment.

The two segments of code are not nearly equivalent. In function however, because Method 1 could create many duplicates.

靑春怀旧 2024-08-13 16:32:53

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

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

Without actually testing I would expect that caching the field values in Wrapper (that is, avoiding all the ToString calls and casts) would probably have more of an impact on performance.

Then once you are caching those values you will probably want to keep instances of Wrapper around rather than frequently recreate them.

放肆 2024-08-13 16:32:53

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

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

Assuming that you're really worried about per (hey, it happens) then your underlying wrapper itself could be improved. You're doing field lookups by string. If you're going to make the call a lot with the same field set in the row, it's actually faster to cache the ordinals and look up by ordinal.

Of course this is only if you really, really need to worry about performance, and the instances where this would make a difference are fairly rare (though in embedded devices it's not as rare as on the desktop).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文