blocks|key|4633915|text|我严重怀疑除了一些IDE影响之外，是否会有任何性能影响。一旦编译好了，我想它不会有什么不同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4633916|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I seriously doubt there would be any performance implications outside of perhaps some IDE impact. Once compiled I wouldn't expect it would make any difference.

blocks|key|2735580|text|我想What+overhead+is+associated+with+an+extension+method+at+runtime?+(.NET)回答了你的问题。扩展方法只是静态方法，所以它们不属于对象类型。Intellisense只会让它看起来如此。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2735581|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1442866/what-overhead-is-associated-with-an-extension-method-at-runtime-net^0|2|1Z|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

<a href="https://stackoverflow.com/questions/1442866/what-overhead-is-associated-with-an-extension-method-at-runtime-net">What overhead is associated with an extension method at runtime? (.NET)</a> answers your question I think. Extension methods are just static methods, so they do not belong on the Object type. Intellisense only makes it seem so.

blocks|key|4634003|text|与之前调用ToString时相比，对FormatSomething的调用并不是真的(您是空的，检查可能需要更多毫秒，但它们也使代码更健壮。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4634004|即使调用该方法的对象的编译时类型是string，它仍然会产生明显的差异。|4634005|在遇到性能问题之前，不要担心性能问题。在此之前，要考虑可维护性，包括可读性。如果你有一个性能问题，那么使用一个分析器来找出它在哪里。|4634006|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Compared to when you call ToString befor the call to FormatSomething not really (you're null check might take a few more ms but they also make the code more robust.

Even if the compile time type of the object you're calling the method on was string it still would make a visible difference. 

Don't worry about performance until you have a performance issue. Until then worry about maintainability including readability. If you have a performance problem then use a profiler to find where it is.

blocks|key|2735681|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2735682|创建操作对象类型的扩展方法是否会影响性能？|blockquote|2735683|2735684|2735685|是。如果传入一个值类型，则该值类型将被装箱。这会造成分配盒子并进行复制的性能损失，当然，之后还必须对盒子进行垃圾回收。|2735686|而不是|2735687|public+static+string+FormatSomething(this+object+o)+
{
++++return+(o+!=+null)+?+o.ToString()+:+"";
}|code-block|syntax|javascript|2735688|我会写下|2735689|public+static+string+FormatSomething<T>(this+T+o)+
{
++++return+(o+!=+null)+?+o.ToString()+:+"";
}|2735690|这有相同的效果，但避免了拳击惩罚。或者更确切地说，它用每次调用的装箱代价来换取第一次调用的代价。|2735691|2735692|从性能的角度来看，在object上创建所有的扩展方法可以吗？|2735693|2735694|2735695|我们不能回答这个问题。试试看！测量性能，将其与期望的性能进行比较，并查看您是否达到了目标。如果你有，那就太好了。如果没有，使用分析器，找到最慢的东西，并修复它。|2735696|但是这两个问题都不是你应该问的问题，你应该问的问题是：|offset|length|style|BOLD|2735697|2735698|创建一个扩展所有东西的扩展方法是一种好的编程实践吗？|2735699|2735700|2735701|不是的。这几乎从来都不是一个好主意。在人们想要这样做的大多数情况下，他们滥用了扩展方法机制。通常，有一些更具体的类型可以扩展。如果你经常这样做，那么你最终会在每种类型上使用大量的扩展方法，并且编码变得令人困惑和容易出错。|2735702|例如，假设您想要一个扩展方法来回答“这个序列包含这个值吗？”这个问题。你可以这样写：|2735703|public+static+bool+IsContainedIn<T>(this+T+item,+IEnumerable<T>+sequence)|2735704|然后说|2735705|if+(myInt.IsContainedIn(myIntSequence))|2735706|但更好的说法是：|2735707|public+static+bool+Contains<T>(this+IEnumerable<T>+sequence,+T+item)|2735708|2735709|if+(myIntSequence.Contains(myInt))|2735710|如果你使用第一种方法，那么你就是在集成开发环境中输入，每次你输入".“时，你都会得到一个IsContainedIn选项的提示，因为你可能要编写代码来确定这个对象是否在集合中。但99%25的情况下，你不会这么做。这样做会增加工具的噪声，并且更难找到您真正想要的东西。|CODE|2735711|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|I|0|0|0|0|0|0|0|0|0|0|0|0|0|0|18|D|0^^$0|@$1|2|3|-4|4|5|6|1Y|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1Z|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|20|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|21|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|22|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|23|7|@]|8|@]|9|$]]|$1|J|3|K|4|L|6|24|7|@]|8|@]|9|$M|N]]|$1|O|3|P|4|5|6|25|7|@]|8|@]|9|$]]|$1|Q|3|R|4|L|6|26|7|@]|8|@]|9|$M|N]]|$1|S|3|T|4|5|6|27|7|@]|8|@]|9|$]]|$1|U|3|-4|4|5|6|28|7|@]|8|@]|9|$]]|$1|V|3|W|4|C|6|29|7|@]|8|@]|9|$]]|$1|X|3|-4|4|5|6|2A|7|@]|8|@]|9|$]]|$1|Y|3|-4|4|5|6|2B|7|@]|8|@]|9|$]]|$1|Z|3|10|4|5|6|2C|7|@]|8|@]|9|$]]|$1|11|3|12|4|5|6|2D|7|@$13|2E|14|2F|15|16]]|8|@]|9|$]]|$1|17|3|-4|4|5|6|2G|7|@]|8|@]|9|$]]|$1|18|3|19|4|C|6|2H|7|@]|8|@]|9|$]]|$1|1A|3|-4|4|5|6|2I|7|@]|8|@]|9|$]]|$1|1B|3|-4|4|5|6|2J|7|@]|8|@]|9|$]]|$1|1C|3|1D|4|5|6|2K|7|@]|8|@]|9|$]]|$1|1E|3|1F|4|5|6|2L|7|@]|8|@]|9|$]]|$1|1G|3|1H|4|L|6|2M|7|@]|8|@]|9|$M|N]]|$1|1I|3|1J|4|5|6|2N|7|@]|8|@]|9|$]]|$1|1K|3|1L|4|L|6|2O|7|@]|8|@]|9|$M|N]]|$1|1M|3|1N|4|5|6|2P|7|@]|8|@]|9|$]]|$1|1O|3|1P|4|L|6|2Q|7|@]|8|@]|9|$M|N]]|$1|1Q|3|1J|4|5|6|2R|7|@]|8|@]|9|$]]|$1|1R|3|1S|4|L|6|2S|7|@]|8|@]|9|$M|N]]|$1|1T|3|1U|4|5|6|2T|7|@$13|2U|14|2V|15|1V]]|8|@]|9|$]]|$1|1W|3|-4|4|5|6|2W|7|@]|8|@]|9|$]]]|1X|$]]

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

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 

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

I would write

<pre><code>public static string FormatSomething&lt;T&gt;(this T o) 
{
 return (o != null) ? o.ToString() : "";
}
</code></pre>

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.

<blockquote>
 is it fine from performance standpoint to create all the extension methods on object?
</blockquote>

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:

<blockquote>
 Is it a good programming practice to create an extension method that extends everything?
</blockquote>

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:

<pre><code>public static bool IsContainedIn&lt;T&gt;(this T item, IEnumerable&lt;T&gt; sequence)
</code></pre>

and then say

<pre><code>if (myInt.IsContainedIn(myIntSequence))
</code></pre>

But it is much better to say:

<pre><code>public static bool Contains&lt;T&gt;(this IEnumerable&lt;T&gt; sequence, T item)
</code></pre>

and then say

<pre><code>if (myIntSequence.Contains(myInt))
</code></pre>

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 <code>IsContainedIn</code> 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.

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

<pre><code>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.

}
</code></pre>

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

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

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

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一组用于各种UI任务的扩展方法。我通常将它们定义为从object类型运行，即使在它们内部，我通常将它们转换为字符串类型。public static string FormatSomething(this object o){     if( o != null )     {          string s =...

问创建操作类型为“object”的扩展方法是否会影响性能？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问创建操作类型为“object”的扩展方法是否会影响性能？EN