c# - 创建以 'object' 类型运行的扩展方法是否会影响性能？

Question

我有一组扩展方法，经常用于各种 UI 任务。我通常将它们定义为 object 类型，即使在它们内部我通常将它们转换为字符串类型。

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.

}

我使用类型 object 的主要原因而不是 string是为了让自己在 UI 中不必做 <%#Eval("Phone").ToString().FormatSomething()%>我什么时候可以做<%#Eval("Phone").FormatSomething()%>相反。

那么，从性能的角度来看，在 object 上创建所有扩展方法是否合适？ , 或者我应该将它们转换为 string (或相关)类型基于扩展方法的作用？

Answer 1

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

是的。 如果您传递一个值类型，那么该值类型将被装箱。这会导致分配箱子和进行复制的性能损失，当然还有以后必须对箱子进行垃圾回收。

代替

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

我会写

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

这具有相同的效果，但避免了拳击惩罚。或者更确切地说，它用每次调用 拳击惩罚换取第一次调用 jitting 成本惩罚。

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

我们无法回答这个问题。试试看!衡量绩效，将其与期望的绩效进行比较，看看是否达到了目标。如果你这样做了，太好了。如果不是，请使用分析器，找到最慢的部分并修复它。

但这两个问题都不是你应该问的问题。你应该问的问题是:

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

没有。这几乎不是一个好主意。在大多数情况下，人们想要这样做，他们是在滥用扩展方法机制。通常有一些更具体的类型可以扩展。如果你经常这样做，那么你最终会在每种类型上都有很多扩展方法，并且编码会变得困惑且容易出错。

例如，假设您想要一个扩展方法来回答“这个序列是否包含这个值？”这个问题。你可以这样写:

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

然后说

if (myInt.IsContainedIn(myIntSequence))

但更好的说法是:

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

然后说

if (myIntSequence.Contains(myInt))

如果您以第一种方式执行此操作，那么您将在 IDE 中进行输入，每次输入“.”时，系统都会提示您使用 IsContainedIn 作为选项，因为可能 您将要编写代码来确定此对象是否在集合中。但 99% 的时间，你不会那样做。这样做会增加工具的噪音，使找到您真正想要的东西变得更加困难。