I was just looking at the question "SubQuery using Lambda Expression" and wondered about compiler optimization of Linq predicates.
Suppose I had a List<string> called names, and I was looking for the items with the shortest string length. So we have the query names.Where(x => x.Length == names.Min(y => y.Length)) (from the question mentioned above). Simple enough.
Now, we know the C# specification does not allow you to modify a collection while enumerating it. So I believe it is technically safe to assume the above call to Min() will always return the same value for every call.
But, my hypothesis is the compiler truly has no way of knowing what the lambda inside the Enumerable.Min extension method returns. Since, for example we could do:
int i = 0;
return names.Where(x => x.Length == names.Min(y => ++i));
Which would mean the query in question is really O(n²) - the result of Min() will be calculated for each iteration. And to get the desired O(n) implementation, you would have to be explicit:
int minLength = names.Min(y => y.Length);
return names.Where(x => x.Length == minLength);
Is my hypothesis correct, or is there something special about Linq or the C# specification that allows the compiler to look inside the lambda and optimize this call to Min()?
#spender is absolutely correct. Consider the following snippet:
List<string> names = new List<string>(new[] { "r", "abcde", "bcdef", "cdefg", "q" });
return names.Where(x =>
{
bool b = (x.Length == names.Min(y => y.Length));
names = new List<string>(new[] { "ab" });
return b;
});
This will return only "r", and not "q", because while the old reference to names is being iterated (foreach x), the call to Min after the first iteration is actually called with the new instance of names. But, a human looking at the query in the top of the question can say for certain nothing gets modified. So my question still stands: is the compiler smart enough to see this?
wondered about compiler optimization of Linq predicates.
The C# compiler does not know how the BCL types are implemented. It could look at the assemblies that you reference but those can change at any time. The compiler cannot assume that the machine the compiled program will run on will have the same binaries. Therefore, th C# compiler cannot legally perform these optimizations because you could tell the difference.
The JIT is in a position to make such optimizations (it does not at the moment).
Now, we know the C# specification does not allow you to modify a
collection while enumerating it. So I believe it is technically safe
to assume the above call to Min() will always return the same value
for every call.
The specification of C# knows nothing about libraries. It does not say this at all. Each implementation of IEnumerable can decide whether it wants to allows such behavior or not.
But, my hypothesis is the compiler truly has no way of knowing what
the lambda inside the Enumerable.Min extension method returns.
Yes, it could do anything. At runtime the JIT could deduce such properties but it does not. Note, that deducing even basic facts is hard because there are things like reflection, runtime code generation and multi-threading.
Is my hypothesis correct, or is there something special about Linq or
the C# specification that allows the compiler to look inside the
lambda and optimize this call to Min()?
No. LINQ has library-only optimizations. LINQ to objects is executed exactly as you wrote it. Other LINQ providers do this differently.
If you wonder whether the JIT will perform some advanced optimization the answer is usually no as of .NET 4.5.
C# compiler works in passes. Each pass takes some complex language feature and converts it to simpler. Quite often context is lost in this conversion. Lambda expressions are one of those steps. Each lambda is converted to class and this class is then instantiated and it's main method is passed to the delegate. And the compilation pass doesn't even look inside the lambda. So compiler that produces the IL code doesn't even know there are any lambdas and just sees bunch of classes. And those classes doesn't give him enough information to infer what you propose.
This question already has answers here:
delegate keyword vs. lambda notation
(6 answers)
Closed 9 years ago.
while deepening myself to more advanced features of C#, I came across some code, which I didn't exactly know the difference of. It's about these two lines:
Func<string, int> giveLength = (text => text.Length);
and
Func<string, int> giveLength = delegate(string text) { return text.Length; };
This can be used in the same way:
Console.WriteLine(giveLength("A random string."));
So basically.. What is the difference of these two lines? And are these lines compiling to the same CIL?
They're the same, basically. They're both anonymous functions in C# specification terminology.
Lambda expressions are generally more concise, and can also be converted to expression trees, which are crucial for out-of-process LINQ.
Anonymous methods allow you to drop the parameter list if you don't care. For example:
EventHandler handler = delegate {
Console.WriteLine("Sender and args don't matter");
};
Given how rarely the latter point is required, anonymous methods are becoming an endangered species in modern C#. Lambda expressions are much more common.
So basically.. What is the difference of these two lines? And are these lines compiling to the same CIL?
There's just two different ways to write the same thing. The lambda syntax is newer and more concise, but they do the same thing (in this case).
Note that lambdas (=> syntax) can also be used to form Expression Lambdas, where you make an Expression Tree instead of a delegate. This is nice since you can use the same syntax whether you're using LINQ to Objects (which is based around delegates like Func<T, TResult>) or LINQ to Entities (which uses IQueryable<T> and expression trees).
Some operations in C# seem needlessly bulky compared to other languages. For example lambdas:
students.GroupBy(student => student.State).Where(student => student.Count > 1).OrderByReversed(studentGroup => studentGroup.Count);
This could be shortened by using really short variable names:
students.GroupBy(s => s.State).Where(s => s.Count > 1).OrderByReversed(sg => sg.Count);
But this way the variables are hard to understand outside of the context. A way to shorten it even further is to simply skip the single-parameter listing entirely, and have the parameter be implied by the dot:
students.GroupBy(.State).Where(.Count > 1).OrderByReversed(.Count);
To me this is a bit more readable than either of the above. It would apply for single-parameter lambdas only and of course it's meaning is inferred from context.
Edit: for lambdas where the parameter itself is used directly '.' could be used as a direct placeholder:
var lines = text.Split("\n").Where(line => line != "");
Could be shortened a bit using:
var lines = text.Split("\n").Where(. != "");
Another place this sort of inferrant operator could be used is in Enum passing. Often the name of the enum is passed too much when it is obvious from context which it is. For example working with OpenTK (a C# implementation of OpenGL), creating a simple textures requires calling something like this every time:
GL.TexImage2D(TextureTarget.Texture2D, 0, PixelInternalFormat.Rgba, bd.Width, bd.Height, 0, OpenTK.Graphics.OpenGL.PixelFormat.Bgr, PixelType.UnsignedByte, myPointer);
GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureMinFilter, (int)TextureMinFilter.Linear);
GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureMagFilter, (int)TextureMagFilter.Linear);
(Note that OpenTK.Graphics.OpenGL.PixelFormat has to be passed with the full name since it conflicts with System.Drawing.Imaging.PixelFormat; using the dot notation this is no longer necessary)
This contains a lot of enum callings which in the equivalent C++ implementation are much shorter, and thus easier to read at first glance. We could try to skip the enum names, and have them be inferred from the context (the called method's parameter type):
GL.TexImage2D(.Texture2D, 0, .Rgba, bd.Width, bd.Height, 0, .Bgr, .UnsignedByte, myPointer);
GL.TexParameter(.Texture2D, .TextureMinFilter, (int).Linear);
GL.TexParameter(.Texture2D, .TextureMagFilter, (int).Linear);
This is not only short but it's even shorter than the C++ equivalent, easy to read while preserving the strongly-typed nature of the language. I'm sure there are other places where it could be used, these are just some examples of syntax I'd love to see in some future C# version. What do you think, would it be a good idea?
Regarding your first example, suppose we see
(x,y) => .z + .q;
Is z a member of x or of y ? What if both x and y have a member called z ?
Not sure how much this is a question, but I'll try to put my two cents in.
The one feature I missed from VB is the [With][1] statement. It sure can lead to horrible messes (just imagine what nested With's do) but it did save a few keystrokes, and also made the code more visually explicit (in a sence that "this is where I set the properties of the SqlConnection object"). Then came Object Inicializers in C# 3, a similar (and better designed) feature and they usually suffice for most With scenarios.
The C# team has been wonderfull in making the developers focus on the what instead of the how, removing superfluous syntax all over the place. "lambda"'s existed in C# 2, only they were called anonymous delegates, and their syntax was something like:
itemTypes.Find(delegate(ItemType itemType) { return itemType.Name == typeName; });
which in c# 3 was shortened to
itemTypes.Find(itemType => itemType.Name == typeName);
This is just one example in how the syntax was streamlined to be easier and more obvious to use, and that increased the visibility of the feature. I don't know many developers who used, or even knew how to use anonymous delegates, but now, it's expected that any C# developer worth his salt should be comfortable with lambdas.
Now, looking at your proposed features, let's weight the pros and the cons (from a developer perspective, not from a language design perspective):
Pro:
Shortness of syntax
Increased ease of use in most usage scenarios
Implicit gain => Easier to train new disciples in the dark art that is C#
Con (lambdas):
Confusion in two or more parameter methods (this can be solved by, well, making it illegal for two parameter methods)
Confusion in nested lambdas (this is the same issue with nested with's - it's just a bad practice)
Con (Enums):
Enums are not really strongly typed, so this might blow up in some scenarios (this is just a feeling, don't have an example)
Bottom line, I would like to see this feature in the case of the lambdas, but it feels a bit iffy in the case of the enums.
Bottomer line, I don't think that there is a real benifit to this feature to justify the change in syntax, so It probably wont be implemented soon (if ever). Tuples and extension properies are still my favorite non-existant features of C#.
I am still learning some of the features of C# 3.0 and want to know if the following can be reduced to a lambda expression.
var SomeObject = Combo.EditValue;
var ObjectProperty = SomeObject.Property;
To obtain ObjectProperty from the combo.editvalue in a single line?
Also, if you can provide me with any good references to Lambda expressions, it would be appreciated.
EDIT: Ok, the answers posted are great, it appears that the example does not need a Lambda to satisfy the solution. I will take a look at the reference links though.
You don't really need lambdas to do that all you would need to do is
var ObjectProperty = Combo.EditValue.Property;
I'm not sure a lambda is going to make that any more readable for you.
Here are some books you might want to take a look at to learn Lambdas in more detail, and also why you'd use them:
More Effective C#
C# In Depth
MSDN Reference
Combining those into one line, you run the risk of a NullReferenceException, by checking the Property property on EditValue. :) But, here is a really great tutorial on C# 3.0 and functional programming.
this does not appear to need a lambda.
Can't you just use
var ObjectProperty = Combo.EditValue.Property
As far as lambda references try 101 LINQ Examples for starters.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
A lot of questions are being answered on Stack Overflow, with members specifying how to solve these real world/time problems using lambda expressions.
Are we overusing it, and are we considering the performance impact of using lambda expressions?
I found a few articles that explores the performance impact of lambda vs anonymous delegates vs for/foreach loops with different results
Anonymous Delegates vs Lambda Expressions vs Function Calls Performance
Performance of foreach vs. List.ForEach
.NET/C# Loop Performance Test (FOR, FOREACH, LINQ, & Lambda).
DataTable.Select is faster than LINQ
What should be the evaluation criteria when choosing the appropriate solution? Except for the obvious reason that it's more concise code and readable when using lambda.
Even though I will focus on point one, I begin by giving my 2 cents on the whole issue of performance. Unless differences are big or usage is intensive, usually I don't bother about microseconds that when added don't amount to any visible difference to the user. I emphasize that I only don't care when considering non-intensive called methods. Where I do have special performance considerations is on the way I design the application itself. I care about caching, about the use of threads, about clever ways to call methods (whether to make several calls or to try to make only one call), whether to pool connections or not, etc., etc. In fact I usually don't focus on raw performance, but on scalibility. I don't care if it runs better by a tiny slice of a nanosecond for a single user, but I care a lot to have the ability to load the system with big amounts of simultaneous users without noticing the impact.
Having said that, here goes my opinion about point 1. I love anonymous methods. They give me great flexibility and code elegance. The other great feature about anonymous methods is that they allow me to directly use local variables from the container method (from a C# perspective, not from an IL perspective, of course). They spare me loads of code oftentimes. When do I use anonymous methods? Evey single time the piece of code I need isn't needed elsewhere. If it is used in two different places, I don't like copy-paste as a reuse technique, so I'll use a plain ol' delegate. So, just like shoosh answered, it isn't good to have code duplication. In theory there are no performance differences as anonyms are C# tricks, not IL stuff.
Most of what I think about anonymous methods applies to lambda expressions, as the latter can be used as a compact syntax to represent anonymous methods. Let's assume the following method:
public static void DoSomethingMethod(string[] names, Func<string, bool> myExpression)
{
Console.WriteLine("Lambda used to represent an anonymous method");
foreach (var item in names)
{
if (myExpression(item))
Console.WriteLine("Found {0}", item);
}
}
It receives an array of strings and for each one of them, it will call the method passed to it. If that method returns true, it will say "Found...". You can call this method the following way:
string[] names = {"Alice", "Bob", "Charles"};
DoSomethingMethod(names, delegate(string p) { return p == "Alice"; });
But, you can also call it the following way:
DoSomethingMethod(names, p => p == "Alice");
There is no difference in IL between the both, being that the one using the Lambda expression is much more readable. Once again, there is no performance impact as these are all C# compiler tricks (not JIT compiler tricks). Just as I didn't feel we are overusing anonymous methods, I don't feel we are overusing Lambda expressions to represent anonymous methods. Of course, the same logic applies to repeated code: Don't do lambdas, use regular delegates. There are other restrictions leading you back to anonymous methods or plain delegates, like out or ref argument passing.
The other nice things about Lambda expressions is that the exact same syntax doesn't need to represent an anonymous method. Lambda expressions can also represent... you guessed, expressions. Take the following example:
public static void DoSomethingExpression(string[] names, System.Linq.Expressions.Expression<Func<string, bool>> myExpression)
{
Console.WriteLine("Lambda used to represent an expression");
BinaryExpression bExpr = myExpression.Body as BinaryExpression;
if (bExpr == null)
return;
Console.WriteLine("It is a binary expression");
Console.WriteLine("The node type is {0}", bExpr.NodeType.ToString());
Console.WriteLine("The left side is {0}", bExpr.Left.NodeType.ToString());
Console.WriteLine("The right side is {0}", bExpr.Right.NodeType.ToString());
if (bExpr.Right.NodeType == ExpressionType.Constant)
{
ConstantExpression right = (ConstantExpression)bExpr.Right;
Console.WriteLine("The value of the right side is {0}", right.Value.ToString());
}
}
Notice the slightly different signature. The second parameter receives an expression and not a delegate. The way to call this method would be:
DoSomethingExpression(names, p => p == "Alice");
Which is exactly the same as the call we made when creating an anonymous method with a lambda. The difference here is that we are not creating an anonymous method, but creating an expression tree. It is due to these expression trees that we can then translate lambda expressions to SQL, which is what Linq 2 SQL does, for instance, instead of executing stuff in the engine for each clause like the Where, the Select, etc. The nice thing is that the calling syntax is the same whether you're creating an anonymous method or sending an expression.
My answer will not be popular.
I believe Lambda's are 99% always the better choice for three reasons.
First, there is ABSOLUTELY nothing wrong with assuming your developers are smart. Other answers have an underlying premise that every developer but you is stupid. Not so.
Second, Lamdas (et al) are a modern syntax - and tomorrow they will be more commonplace than they already are today. Your project's code should flow from current and emerging conventions.
Third, writing code "the old fashioned way" might seem easier to you, but it's not easier to the compiler. This is important, legacy approaches have little opportunity to be improved as the compiler is rev'ed. Lambdas (et al) which rely on the compiler to expand them can benefit as the compiler deals with them better over time.
To sum up:
Developers can handle it
Everyone is doing it
There's future potential
Again, I know this will not be a popular answer. And believe me "Simple is Best" is my mantra, too. Maintenance is an important aspect to any source. I get it. But I think we are overshadowing reality with some cliché rules of thumb.
// Jerry
Code duplication.
If you find yourself writing the same anonymous function more than once, it shouldn't be one.
Well, when we are talking bout delegate usage, there shouldn't be any difference between lambda and anonymous methods -- they are the same, just with different syntax. And named methods (used as delegates) are also identical from the runtime's viewpoint. The difference, then, is between using delegates, vs. inline code - i.e.
list.ForEach(s=>s.Foo());
// vs.
foreach(var s in list) { s.Foo(); }
(where I would expect the latter to be quicker)
And equally, if you are talking about anything other than in-memory objects, lambdas are one of your most powerful tools in terms of maintaining type checking (rather than parsing strings all the time).
Certainly, there are cases when a simple foreach with code will be faster than the LINQ version, as there will be fewer invokes to do, and invokes cost a small but measurable time. However, in many cases, the code is simply not the bottleneck, and the simpler code (especially for grouping, etc) is worth a lot more than a few nanoseconds.
Note also that in .NET 4.0 there are additional Expression nodes for things like loops, commas, etc. The language doesn't support them, but the runtime does. I mention this only for completeness: I'm certainly not saying you should use manual Expression construction where foreach would do!
I'd say that the performance differences are usually so small (and in the case of loops, obviously, if you look at the results of the 2nd article (btw, Jon Skeet has a similar article here)) that you should almost never choose a solution for performance reasons alone, unless you are writing a piece of software where performance is absolutely the number one non-functional requirement and you really have to do micro-optimalizations.
When to choose what? I guess it depends on the situation but also the person. Just as an example, some people perfer List.Foreach over a normal foreach loop. I personally prefer the latter, as it is usually more readable, but who am I to argue against this?
Rules of thumb:
Write your code to be natural and readable.
Avoid code duplications (lambda expressions might require a little extra diligence).
Optimize only when there's a problem, and only with data to back up what that problem actually is.
Any time the lambda simply passes its arguments directly to another function. Don't create a lambda for function application.
Example:
var coll = new ObservableCollection<int>();
myInts.ForEach(x => coll.Add(x))
Is nicer as:
var coll = new ObservableCollection<int>();
myInts.ForEach(coll.Add)
The main exception is where C#'s type inference fails for whatever reason (and there are plenty of times that's true).
If you need recursion, don't use lambdas, or you'll end up getting very distracted!
Lambda expressions are cool. Over older delegate syntax they have a few advantages like, they can be converted to either anonymous function or expression trees, parameter types are inferred from the declaration, they are cleaner and more concise, etc. I see no real value to not use lambda expression when you're in need of an anonymous function. One not so big advantage the earlier style has is that you can omit the parameter declaration totally if they are not used. Like
Action<int> a = delegate { }; //takes one argument, but no argument specified
This is useful when you have to declare an empty delegate that does nothing, but it is not a strong reason enough to not use lambdas.
Lambdas let you write quick anonymous methods. Now that makes lambdas meaningless everywhere where anonymous methods go meaningless, ie where named methods make more sense. Over named methods, anonymous methods can be disadvantageous (not a lambda expression per se thing, but since these days lambdas widely represent anonymous methods it is relevant):
because it tend to lead to logic duplication (often does, reuse is difficult)
when it is unnecessary to write to one, like:
//this is unnecessary
Func<string, int> f = x => int.Parse(x);
//this is enough
Func<string, int> f = int.Parse;
since writing anonymous iterator block is impossible.
Func<IEnumerable<int>> f = () => { yield return 0; }; //impossible
since recursive lambdas require one more line of quirkiness, like
Func<int, int> f = null;
f = x => (x <= 1) ? 1 : x * f(x - 1);
well, since reflection is kinda messier, but that is moot isn't it?
Apart from point 3, the rest are not strong reasons not to use lambdas.
Also see this thread about what is disadvantageous about Func/Action delegates, since often they are used along with lambda expressions.