是否有创建了对象类型操作扩展方法影响性能？ [英] Is there a performance hit for creating Extension methods that operate off the object type?

问题描述

我有一组的，我经常为各种UI任务使用扩展方法。我通常定义它们为关类型的对象上运行，即使他们里面，我通常将它们转换为字符串类型。

 公共静态字符串FormatSomething（该对象o）
{
     如果（O！= NULL）
     {
          字符串s = o.ToString（）;
          ///做的工作并返回的东西。
     }
     //返回别的东西或空字符串。}
 

我用的对象类型，而不是字符串的主要原因是对自己保存在UI不必做＆LT;％＃的eval（手机）的ToString（）FormatSomething（）％ ＆GT; 时，我可以做＆LT;％＃的eval（手机）FormatSomething（）％＆GT; 而不是

那么，是不是从优良性能的角度来看，以创建对象中所有扩展方法，或者我应该将它们转换是基于什么扩展方法是做字符串（或相关）类型？

解决方案

  

有用于创建扩展方法对性能的影响在脱离对象类型？

是的。的如果你再传递值类型的值类型将被装箱。的这造成分配箱，做拷贝，再加上当然后来有垃圾收集箱的性能损失。

而不是

的

 公共静态字符串FormatSomething（该对象o）
{
    返回（O！= NULL）？ o.ToString（）：;
}
 

我会写

 公共静态字符串FormatSomething＆LT; T＆GT;（这件T O）
{
    返回（O！= NULL）？ o.ToString（）：;
}
 

这有同样的效果，但避免了装箱损失。或者说，它换一个的每次通话的装箱损失了的第一个电话的jitting成本损失。

  

这是从优良性能的角度来看，以创建对象中所有扩展方法？

我们不能回答这个问题。尝试一下！衡量性能，比较，对所需的性能，看看你是否达到目标。如果你做了，太棒了。如果没有，使用一个分析器，找到最慢的东西，并修复它。

但是，无论问题是，你应该问的问题您应该问的问题是：

  

这是个良好的编程习惯创建一个扩展的一切扩展方法？

没有。这是几乎从来没有一个好主意。在人们想要做的，大多数情况下，它们被滥用扩展方法的机制。通常有一些可能被延长更具体的类型。如果你这样做了很多，那么你最终与很多在每一个类型的扩展方法，以及编码变得扑朔迷离，而且容易出错。

例如，假设你想有一个回答问题的扩展方法没有这个序列包含这个价值呢？你可以写：

 公共静态布尔IsContainedIn＆LT; T＆GT;（这件T项目，IEnumerable的＆LT; T＆GT;序列）
 

然后说

 如果（myInt.IsContainedIn（myIntSequence））
 

但它是更好地说：

 公共静态布尔包含＆LT; T＆GT;（这个IEnumerable的＆LT; T＆GT;序列，T项）
 

然后说

 如果（myIntSequence.Contains（敏））
 

如果你做的第一种方式，然后你在IDE中，你键入每一次敲字。，你得到提示 IsContainedIn 作为一个选项因为的也许的你要写code，它确定这个对象是一个收藏。但是，99％的时间，你不打算这样做。这样做增加了噪音的工具，使得它很难找到你真正想要的东西。

I have a set of extension methods that I regularly use for various UI tasks. I typically define them to run off of type object, even though inside of them I'm typically converting them to string types.

public static string FormatSomething(this object o)
{
     if( o != null )
     {
          string s = o.ToString();
          /// do the work and return something.
     }
     // return something else or empty string.

}

The main reason I use the object type and not string is to save myself in the UI from having to do <%#Eval("Phone").ToString().FormatSomething()%> when I can do <%#Eval("Phone").FormatSomething()%> instead.

So, is it fine from performance standpoint to create all the extension methods on object, or should I convert them to be string (or relevant) types based on what the extension method is doing?

解决方案

Is there a performance hit for creating extension methods that operate off the object type?

Yes. If you pass a value type in then the value type will be boxed. That creates a performance penalty of allocating the box and doing the copy, plus of course later having to garbage collect the box.

Instead of

public static string FormatSomething(this object o) 
{
    return (o != null) ? o.ToString() : "";
}

I would write

public static string FormatSomething<T>(this T o) 
{
    return (o != null) ? o.ToString() : "";
}

That has the same effect, but avoids the boxing penalty. Or rather, it trades a per call boxing penalty for a first call jitting cost penalty.

is it fine from performance standpoint to create all the extension methods on object?

We cannot answer the question. Try it! Measure the performance, compare that against the desired performance, and see if you met your goal. If you did, great. If not, use a profiler, find the slowest thing, and fix it.

But neither question is the question you should be asking. The question you should have asked is:

Is it a good programming practice to create an extension method that extends everything?

No. It is almost never a good idea. In most cases where people want to do that, they are abusing the extension method mechanism. Typically there is some more specific type that could be extended. If you do this a lot then you end up with lots of extension methods on every type, and coding becomes confusing and error-prone.

For example, suppose you want to have an extension method that answers the question "does this sequence contain this value?" You could write:

public static bool IsContainedIn<T>(this T item, IEnumerable<T> sequence)

and then say

if (myInt.IsContainedIn(myIntSequence))

But it is much better to say:

public static bool Contains<T>(this IEnumerable<T> sequence, T item)

and then say

if (myIntSequence.Contains(myInt))

If you do it the first way then you're typing along in the IDE and every single time you type ".", you get prompted with IsContainedIn as an option because maybe you're about to write code that determines if this object is in a collection. But 99% of the time, you're not going to do that. Doing this adds noise to the tooling and makes it harder to find what you really want.

这篇关于是否有创建了对象类型操作扩展方法影响性能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！