|
Regardless, debugging is still harder with chains of linq statements, that's the only point I was making.
|
|
|
|
|
Richard Deeming wrote: Writing all of your code in one big Main function is faster than any of this "object-oriented" nonsense.
That is, almost certainly, not true. With one big function, the optimizer will have to practically shut-down. Many smaller functions can be highly optimized.
Richard Deeming wrote: And using C or assembly will be much faster than this JIT-compiled C# nonsense.
Again, real world examples have shown that letting the computer do things like managing your resources, is much faster than trying to do it yourself manually.
Truth,
James
|
|
|
|
|
I would be a bit surprised if your first point was true. Please give me a couple examples of optimizations that depend on function size.
|
|
|
|
|
Optimization largely depends on tracking the lifetime of variables:
for(int i =0; i< 100; ++i)
{...}
will be better optimized, than this...
int i;
for(i =0; i< 100; ++i)
{...}
just because the compiler knows that "i" is never used again outside that for loop. In the latter, space must be allocated for i on the stack, and it must be stored there. In the first, "i" may live at it's entire existence in a register.
Now, in an example as small as the above, a good compiler may still realize that even the second "i" is not used again, but the larger that function gets, with more things to track, the optimizer begin to give up.
Truth,
James
|
|
|
|
|
That might be true but it comes at the cost of jumps and stack management for function calls. I think you will be hard-pressed to find an example of one block of code that runs slower than similar code split into more functions.
|
|
|
|
|
But then, what about library functions? Are you going to inline every call to ToUpper() or Trim()?
If you do, you have a unmanageable mess.
If you don't, then you're back to the costs of jumps and stack management, so what's a few more?
Truth,
James
|
|
|
|
|
"What's a few more" is often significant overhead.
I don't know what argument you think I'm making. The comment that is the topic of my comments simply said that writing your code in a big main function is faster that all this object oriented stuff but probably a bad idea. I'm agreeing with that.
|
|
|
|
|
Mike Marynowski wrote: I would be a bit surprised if your first point was true. Please give me a couple examples of optimizations that depend on function size.
Small functions can be in-lined by the optimiser, so this code
foreach(string x in y)
{
x = x.Trim().ToLower();
DoSomething (x);
}
function DoSomething(string s)
{
if (s.StartsWith("hello"))
{
s = "test";
}
}
might be optimised to this
foreach(string x in y)
{
x = x.Trim().ToLower();
if (x.StartsWith("hello"))
{
x = "test";
}
}
thus avoiding a code jump\stack update etc.
|
|
|
|
|
Yes, but that optimization doesn't have to be made if you are putting everything into a big block of code lol. I'm not advocating for that approach, just saying that splitting into functions is unlikely to boost performance...in the best case it will match performance after optimizations, which is basically what is happening in this example.
|
|
|
|
|
I think I need to buy one of those "sarcasm" flags.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Well I do find it a lot faster to write. I would expect it to have poorer performance, but don't know how bad. I believe is that if you have performance issues, find out the methods that use the most resources, and optimize them. This is where get most bang for the buck.
|
|
|
|
|
I use it - though not the .ForEach on the end - because there are times when it provides a reliable, succinct, and clear way to process list (or other collection) based data.
var vidsWithOutPics = vidList.Except(vidsWithPics).Where(v => !v.IsAlternateTitle);
Or
var inDuration = DiskFile.GetAll().Where(df => !df.HasDuration).Select(df => df.Video).Distinct();
Or
var noSizeList = videoFiles.Where(file => file.Bytes < 0 && files.Contains(file.Location));
All I'm doing is "hiding" the loop so I don't have to write it!
Yes, I could write each of those as loops - they aren't at all complex - but they would be longer; they would need debugging each time I wrote them.
The other alternative would be to use Linq syntax, and that's pretty horrible!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
But surely you need to debug this as well? Just in case? And that would be harder than if it were a normal loop
|
|
|
|
|
Yes - but you need to debug the criteria it's using rather than the complete code - which isn't complicated. Would you like to write and debug "Except" each time you need it?
No - so you'd write it once and call it from multiple places. Which is exactly what I do when I use aCollection.Except(anotherCollection) - except I don't have to write it in the first place!
And you have to admit that
var inDuration = DiskFile.GetAll().Where(df => !df.HasDuration).Select(df => df.Video).Distinct(); Is a lot more readable than the "home brew" version using methods:
var inDuration = Distinct(Select(Where(DiskFile.GetAll(), Video), HasDuration));
Where it's a PITA to just make sure the brackets match up!
Yes, Linq methods can be slower to execute - but sometimes the absolute speed isn't that important, but reliability and ease of maintenance is.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: Would you like to write and debug "Except" each time you need it? Actually yes, so I wouldn't end up in that situation of horribly nested function calls in your second code block.
|
|
|
|
|
Instead having loads of repeated code everywhere for no real benefit? are you trolling?
|
|
|
|
|
It's literally a single "if" that's added into a loop. That's not enough to refactor out of it, anything it can be replaced by is at least as complicated. Writing an "except" method is certainly more complicated, and calling it isn't any simpler than what it replaces.
|
|
|
|
|
this thread only shows that you're hellbent on your "One true way" of coding, so there's not much to discuss here.
but do keep in mind that calling a style "cancer" just because you don't want to learn how to read and use it is exactly what causes so many flamewars on the IT world (tabs vs spaces anyone?). Sure, you tell me it's just an if but you know what? I much prefer to read
someList.Where(condition).Select(fields).Distinct().OrderBy(field)
than the alternative
HashSet<Type> distinctSet = new HashSet<Type>();
foreach(var item in someList){
if(condition){
distinctSet.Add(item);
}
}
<sort the set in whatever way you do it manually>
specially if you want to roll your own sorting method at the end.
As a last note, i sometimes work with code where the order of operations (where, distinct, etc) sometimes yields different results and is important (due to crazy business rules, what can you do), so it's way easier to get the intent from the link way, but I recognize that you mileage may vary on that last one.
|
|
|
|
|
I promise you I'm not just flaming, I just really find those chained LINQy things hard to read. It's not like I haven't tried, I've been reading them for nearly a decade, I'm not getting used to them. It takes an extra step in my mind somehow, normal code I read and build up a picture of it in my mind, LINQy stuff I read, tear down, then build a picture. Clearly that is not the case for everyone here
|
|
|
|
|
It was hard for me too, but once you understand how the context shifts it becomes way easier. LINQ queries have a different flow from the rest of the imperative code and are best left a little separated from stuff like for loops and complex conditionals, they require you to use the same way of thinking you use when writing SQL. It's not that you are telling the machine what to do, you're telling it what you want done, so you read this:
someList.Where(condition).Select(field)
As "Give me field for all objects where condition is true" instead of "For each object, if condition is true, stuff field on another list".
Truth is, those kind of LINQ queries are just convenience. The real power of LINQ comes when you start using joins and groups, like this example from LINQPad (still on the simple side):
var query =
from o in Orders
group o by o.ShipCountry into countryGroups
select new
{
Country = countryGroups.Key,
Cities =
from cg in countryGroups
group cg.ShipPostalCode by cg.ShipCity into cityGroups
select new
{
City = cityGroups.Key,
PostCodes = cityGroups.Distinct()
}
};
that produces this output:
As much as I can write that using for loops and conditionas, i don't want to write it that way. Also, join's and group's are the only thing I'll ever use query syntax for, they are somewhat easier to understand that way.
|
|
|
|
|
Harold, is it easier on separate lines, or do you still find that difficult to read? (by the way, this is called "fluent syntax". I find when it's all on one line (except maybe calling .Single() or .First() or .ToList() at the end of something) it can be very difficult to read. But this I love:
someStuff.Where(c => c != What)
.Select(d => d + The)
.Foreach(e => Hell(e));
|
|
|
|
|
I can certainly understand, especially when you are dealing with SelectMany, or Join. Those can get nasty, but then the code to do them would be nasty anyway. so I do not see a good reason to code it with foreach and if statements.
|
|
|
|
|
Sentenryu wrote: calling a style "cancer" just because you don't want to learn how to read and use it
OP reminds me of this[^]
|
|
|
|
|
Linq is all about defining the query instead of the execution of the query. You say you can implement Except in a single line of code. Can you also do that for grouping, ordering, projection? And all those other possibilities, all used in combination?
Using Ling you are sacrificing a little performance, and you are (read: should be) gaining a lot in maintenance. You can implement the above probably without problems. Can you also read the implementation of others without any problems? Using Linq you and your co-workers are all using the same methods, and therefor, can read each others code a lot easier, compared to a different implementation for you and every co-worker you have.
Of course, you can completely kill the performance, and no-one will say that Linq is faster, and yes, you have to know what you are doing. But that is no different from all the 'other tools in your toolbox'.
|
|
|
|
|
Linq => Backward SQL
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|