blocks|key|1976268|text|我必须同意你的观点--如果写起来更有效率，更优雅，那么几毫秒就好了。编写额外的代码为bug提供了更多的空间，需要测试的是额外的代码，最重要的是需要维护额外的代码。想想你后面的那个家伙，他们会感谢你写得很好，容易读的代码，然后再感谢你写的代码快几毫秒！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1976269|不过，如果考虑到更大的情况，这几个ms的成本可能会很大。如果这几毫秒是数千次重复循环的一部分，那么毫秒加起来很快。|1976270|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I have to agree with your view - if it's more efficient to write and elegant then what's a few milliseconds. Writing extra code gives more room for bugs to creep in and it's extra code that needs to be tested and most of all it's extra code to maintain. Think about the guy who's going to come in behind you and maintain your code - they'll thank you for writing elegant easy to read code long before they thank you for writing code that's a few ms faster!

Beware though, this cost of a few ms could be significant when you take the bigger picture into account. If that few milliseconds is part of a loop of thousands of repetitions, then the milliseconds add up fast.

blocks|key|442653|text|是的，你可以太爱LINQ了-+单语句LINQ+RayTracer|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|442654|你在哪里划界线？我认为使用LINQ可以使代码更简单、更容易阅读。|442655|当LINQ版本变得比非LINQ版本更难理解的时候，就该交换了，反之亦然。编辑:这主要适用于LINQ到对象，因为其他LINQ口味有自己的好处。|442656|entityMap|0|LINK|mutability|MUTABLE|url|http://tirania.org/blog/archive/2007/Nov-16.html^0|F|H|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

Yes you can love LINQ too much - <a href="http://tirania.org/blog/archive/2007/Nov-16.html" rel="noreferrer">Single Statement LINQ RayTracer</a>

Where do you draw the line? I'd say use LINQ as much as it makes the code simpler and easier to read. 

The moment the LINQ version becomes more difficult to understand then the non-LINQ version it's time to swap, and vice versa. EDIT: This mainly applies to LINQ-To-Objects as the other LINQ flavours have their own benefits.

blocks|key|442638|text|不可能对对象太爱Linq了，这是一种非常棒的技术！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|442639|但是说真的，任何使您的代码易于阅读、易于维护和完成它所期望的工作的东西，如果您不尽可能多地使用它，那就太愚蠢了。|442640|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Its not possible to love Linq to Objects too much, it's a freaking awesome technology !

But seriously, anything that makes your code simple to read, simple to maintain and does the job it was intended for, then you would be silly not to use it as much as you can.

blocks|key|442478|text|LINQ应该用来使来自不同来源的数据的过滤、排序、聚合和操作尽可能直观和有表现力。我想说，只要你觉得它是最整洁、最有表现力和最自然的语法，就用它来做你想做的事情，不要为此感到内疚。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|442479|如果你开始整理文档，那么也许是时候重新考虑你的立场了。|442480|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

LINQ's supposed to be used to make filtering, sorting, aggregating and manipulating data from various sources as intuitive and expressive as possible. I'd say, use it wherever you feel it's the tidiest, most expressive and most natural syntax for doing what it is you're trying to do, and don't feel guilty about it.

If you start humping the documentation, then it may be time to reconsider your position.

blocks|key|442515|text|在这种情况下，记住优化的黄金规则是很重要的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|442516|别这么做|ordered-list-item|442517|专家:先别这么做|442518|您绝对应该而不是担心“滥用”linq，除非您可以显式地将它识别为导致性能问题的原因。|offset|length|style|BOLD|442519|entityMap^0|0|0|0|5|3|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|Q|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|R|8|@$I|S|J|T|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|N|$]]

It's cases like these where it's important to remember the golden rules of optimization:

<ol>
<li>Don't Do It</li>
<li>For Experts: Don't do it yet</li>
</ol>

You should absolutely not worry about "abusing" linq unless you can indentify it explicitly as the cause of a performance problem

blocks|key|442590|text|就像任何东西一样，它可以被滥用。只要你远离明显的错误决定，比如|type|unstyled|depth|inlineStyleRanges|entityRanges|data|442591|var+v+=+List.Where(...);
for(int+i+=+0;+i+<+v.Count();+i%2B%2B)
{...}|code-block|syntax|javascript|442592|并且了解不同的执行方式，那么它很可能不会比长时间的方式慢得多。根据Anders+(C#架构师)的说法，C#编译器并不擅长优化循环，但是它在优化和并行化表达式树方面正变得更好。随着时间的推移，它可能比循环更有效。List<>的ForEach版本实际上和for循环一样快，尽管我找不到证明这一点的链接。|442593|我个人最喜欢的是ForEach<‘>的表亲IndexedForEach+(利用扩展方法)|442594|List.IndexedForEach(+(p,i)+=>+
+{
+++++if(i+!=+3)
++++++++p.DoSomething(i);
+};|442595|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|S|8|@]|9|@]|A|$E|F]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Like anything, it can be abused. As long as you stay away from obvious poor decisions such as 

<pre><code>var v = List.Where(...);
for(int i = 0; i &lt; v.Count(); i++)
{...}
</code></pre>

and understand how differed execution works, then it is most likely not going to be much slower than the longhand way. According to Anders Hejlsburg (C# architect), the C# compiler is not particularly good at optimizing loops, however it is getting much better at optimizing and parallelizing expression trees. In time, it may be more effective than a loop. The List&lt;>'s ForEach version is actually as fast as a for loop, although I can't find the link that proves that.

P.S. My personal favorite is ForEach&lt;>'s lesser known cousin IndexedForEach (utilizing extension methods)

<pre><code>List.IndexedForEach( (p,i) =&gt; 
 {
 if(i != 3)
 p.DoSomething(i);
 };
</code></pre>

blocks|key|442848|text|林克可以像艺术一样。继续使用它来使代码变得漂亮。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|442849|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|$]]

LINQ can be like art. Keep using it to make the code beautiful.

blocks|key|442448|text|你在回答你自己的问题，你说要为几毫秒的性能写2-3倍的代码。我的意思是，如果您的问题域需要加速，那么是的，如果不可能。然而，它是真的只有几毫秒的性能，还是它>+5%25或>+10%25。这是一个基于个案的价值判断。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|442449|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|$]]

You're answering your own question by talking about writing 2-3 times more code for a few ms of performance. I mean, if your problem domain requires that speedup then yes, if not probably not. However, is it really only a few ms of performance or is it > 5% or > 10%. This is a value judgement based on the individual case.

blocks|key|442679|text|在哪里划清界限？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|442680|嗯，我们已经知道实现您自己的linq中的快速排序是个坏主意，至少与仅仅使用linq的orderby相比是如此。|offset|length|442681|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/185072/learning-linq-quicksort^0|0|E|A|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Where to draw the line?

Well, we already know that it is a bad idea to implement your own <a href="https://stackoverflow.com/questions/185072/learning-linq-quicksort">quicksort in linq</a>, at least compared to just using linq's orderby.

blocks|key|1976435|text|我发现使用LINQ加快了我的开发速度，并且更容易避免循环可能带来的愚蠢错误。我曾经遇到过LINQ性能差的例子，但当我使用它从拥有数百万节点的树结构中为excel文件获取数据时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1976436|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've found that using LINQ has speed up my development and made it easier to avoid stupid mistakes that loops can introduce. I have had instances where the performance of LINQ was poor, but that was when I was using it to things like fetch data for an excel file from a tree structure that had millions of nodes.

blocks|key|754620|text|虽然我看到有一种观点认为LINQ可能会使语句更难读，但我认为，我的方法现在与它们正在解决的问题严格相关，而不是花费时间，包括查找循环或使用专用查找函数的杂乱类，这远远超过了这一事实。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|754621|习惯使用LINQ做事情花了一小段时间，因为循环查找之类的东西很久以来一直是主要的选择。我认为LINQ只是另一种语法糖，可以以更优雅的方式完成同样的任务。现在，我仍然在处理-繁重的任务关键代码-但这只是直到性能随着LINQ的发展而提高。|754622|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

While I see how there is a point of view that LINQ might make a statement harder to read, I think it is far outweighed by the fact that my methods are now strictly related to the problems that they are solving and not spending time either including lookup loops or cluttering classes with dedicated lookup functions.

It took a little while to get used to doing things with LINQ, since looping lookups, and the like, have been the main option for so long. I look at LINQ as just being another type of syntactic sugar that can do the same task in a more elegant way. Right now, I am still avoiding it in processing-heavy mission critical code - but that is just until the performance improves as LINQ evolves.

blocks|key|1976505|text|我对LINQ唯一关心的是它对联接的实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1976506|正如我在尝试回答这个问题+(以及确认的这里)时所确定的那样，LINQ生成的用于执行联接的代码(我猜是必然的)是天真的:对于列表中的每一项，联接都通过连接列表执行线性搜索以找到匹配项。|offset|length|1976507|在LINQ查询中添加一个连接，本质上是将线性时间算法转化为二次时间算法。即使你认为过早的优化是万恶的根源，从O(n)到O(n%5E2)的跳跃也会让你停下来。(如果您也通过连接项连接到另一个集合，则为O(n%5E3)。)|1976508|相对来说，解决这个问题比较容易。例如，这个查询：|1976509|var+list+=+from+pr+in+parentTable.AsEnumerable()
join+cr+in+childTable.AsEnumerable()+on+cr.Field<int>("ParentID")+equals+pr.Field<int>("ID")
where+pr.Field<string>("Value")+==+"foo"
select+cr;|code-block|syntax|javascript|1976510|类似于如何在Server中连接两个表。但是在LINQ中效率很低:对于where子句返回的每个父行，查询都会扫描整个子表。(即使您是在取消索引的字段上加入，Server也会构建一个哈希表，以便在可能的情况下加快联接速度。这有点超出LINQ的工资等级。)|style|CODE|1976511|但是，这个查询：|1976512|string+fk+=+"FK_ChildTable_ParentTable";
var+list+=+from+cr+in+childTable.AsEnumerable()
where+cr.GetParentRow(fk).Field<string>("Value")+==+"foo"
select+cr;|1976513|生成相同的结果，但它只扫描一次子表。|1976514|如果您使用LINQ对象，同样的问题也会出现:如果您想连接两个大小相当大的集合，您可能需要考虑实现一种更有效的方法来查找已连接的对象，例如：|1976515|Dictionary<Foo,+Bar>+map+=+buildMap(foos,+bars);
var+list+=+from+Foo+f+in+foos
where+map[f].baz+==+"bat"
select+f;|1976516|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/387772/does-linq-use-datarelations-to-optimize-joins|1|http://msdn.microsoft.com/en-us/library/bb387080.aspx^0|0|8|4|0|J|2|1|0|0|0|0|Y|5|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@]|9|@$D|1E|E|1F|1|1G]|$D|1H|E|1I|1|1J]]|A|$]]|$1|F|3|G|5|6|7|1K|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1L|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1M|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1N|8|@$D|1O|E|1P|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|U|3|V|5|L|7|1R|8|@]|9|@]|A|$M|N]]|$1|W|3|X|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1T|8|@]|9|@]|A|$]]|$1|10|3|11|5|L|7|1U|8|@]|9|@]|A|$M|N]]|$1|12|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]|1A|$5|15|16|17|A|$18|1B]]]]

My only concern about LINQ is with its implementation of joins. 

As I determined when trying to answer <a href="https://stackoverflow.com/questions/387772/does-linq-use-datarelations-to-optimize-joins">this question</a> (and it's confirmed <a href="http://msdn.microsoft.com/en-us/library/bb387080.aspx" rel="nofollow noreferrer">here</a>), the code LINQ generates to perform joins is (necessarily, I guess) naive: for each item in the list, the join performs a linear search through the joined list to find matches.

Adding a join to a LINQ query essentially turns a linear-time algorithm into a quadratic-time algorithm. Even if you think premature optimization is the root of all evil, the jump from O(n) to O(n^2) should give you pause. (It's O(n^3) if you join through a joined item to another collection, too.)

It's relatively easy to work around this. For instance, this query:

<pre><code>var list = from pr in parentTable.AsEnumerable()
join cr in childTable.AsEnumerable() on cr.Field&lt;int&gt;("ParentID") equals pr.Field&lt;int&gt;("ID")
where pr.Field&lt;string&gt;("Value") == "foo"
select cr;
</code></pre>

is analogous to how you'd join two tables in SQL Server. But it's terribly inefficient in LINQ: for every parent row that the <code>where</code> clause returns, the query scans the entire child table. (Even if you're joining on an unindexed field, SQL Server will build a hashtable to speed up the join if it can. That's a little outside LINQ's pay grade.)

This query, however:

<pre><code>string fk = "FK_ChildTable_ParentTable";
var list = from cr in childTable.AsEnumerable()
where cr.GetParentRow(fk).Field&lt;string&gt;("Value") == "foo"
select cr;
</code></pre>

produces the same result, but it scans the child table once only.

If you're using LINQ to objects, the same issues apply: if you want to join two collections of any significant size, you're probably going to need to consider implementing a more efficient method to find the joined object, e.g.:

<pre><code>Dictionary&lt;Foo, Bar&gt; map = buildMap(foos, bars);
var list = from Foo f in foos
where map[f].baz == "bat"
select f;
</code></pre>

I recently found LINQ and love it. I find lots of occasions where use of it is so much more expressive than the longhand version but a colleague passed a comment about me abusing this technology which now has me second guessing myself. It is my perspective that if a technology works efficiently and the code is elegant then why not use it? Is that wrong? I could spend extra time writing out processes "longhand" and while the resulting code may be a few ms faster, it's 2-3 times more code and therefore 2-3 times more chance that there may be bugs.

Is my view wrong? Should I be writing my code out longhand rather than using LINQ? Isn't this what LINQ was designed for?

Edit: I was speaking about LINQ to objects, I don't use LINQ to XML so much and I have used LINQ to SQL but I'm not so enamoured with those flavours as LINQ to objects.

Where to draw the line - is it possible to love LINQ too much?

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

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

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

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

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

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

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我最近发现了LINQ，我很喜欢它。我发现在很多情况下，它的使用比长篇版本更有表现力，但一位同事发表了一条关于我滥用这项技术的评论，现在我不得不自己去猜测。我的观点是，如果一项技术有效地工作，并且代码很优雅，那么为什么不使用它呢？这样做不对吗？我可以花更多的时间写进程“长时间”，虽然得到的代码可能快几毫秒，但它的代码要多2-3倍，因此有可能出现bug的可能性要高出2-3倍。我的观点错了吗？我应该长时

问何去何从
EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问何去何从EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问何去何从
EN