|
irneb wrote: your sample is quite litterally performing 3 loops where one for loop would have sufficed.
you should really take a look on what the compiler does when it enconters the yield keyword, you might be surprised to find out it's not as inefficient as you think.
|
|
|
|
|
Sentenryu wrote: you should really take a look on what the compiler does when it enconters the yield keyword
Not even slightly sure what you mean by that ???
Here's a test: BenchLinqLoops[^]
The chain of Linq statements clearly perform 3 loops (one of which is unnecessary). Yield doesn't "magically" fix that. And to show by how much such Linq chains (and even the Linq-to-SQL version) adds extra overhead - look at the performance of that yield function.
|
|
|
|
|
And just to make doubly sure no JIT optimizations skew the benchmark - I added an extra loop before starting the stopwatch, and rearranged the orders:
BenchLinqLoops[^]
Now you actually see the SQL variant's "extra" overhead - i.e. being translated into (effectively) the LinqAddXToEven2Loops function before it runs.
|
|
|
|
|
harold aptroot wrote: Is this style cancer?
No.
Linq has both it's Pro's and Con's. However, there is a clear benefit: Easy to write and easy to read (keep in mind that, if using Visual Studio, you have full intellisense support. And you can use your favourite code template, too.)
someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e));
looks better to me than
List<SomeStuff> tmpStuffList = new List<SomeStuff>();
for (int i = 0; i < someStuff.Count - 1; i++)
{
if (someStuff[i] != What)
{
tmpStuffList.Add(someStuff[i]);
}
}
for (int n = 0; n < tmpStuffList.Count - 1; n++)
{
Hell(tmpStuffList[n]);
}
I'll stick to the LinQ way of Querying.
|
|
|
|
|
Well, you did use some unnecessary stuff there.. temporary list isn't necessary, and those -1's should obviously not be there.
|
|
|
|
|
Sorting arrays in asp pages is ok I guess.
For business logic I would recommend an traditional approach.
so, yea, cancer for sure!
//ra
|
|
|
|
|
boss: "we need an else statement adding for when 'c' == Who and to run "Heaven(e)"
programmer: "right, that will be 2 hours."
foreach(var stuff in someStuff) {
if(stuff == What) {
Hell(stuff + The)
}
else if(stuff == Who) {
Heaven(stuff)
}
}
Boss: We all so need to call Devil() for when stuff it is "What".
|
|
|
|
|
harold aptroot wrote: Is this style cancer?
No.
harold aptroot wrote: Side question, why is this style popular?
It's part of the gradual shift from imperative programming to declarative programming. See also: javascript array functions.
|
|
|
|
|
We should be using that syntax because it's cleaner and more readable than lots of indented loops.
Our problems (at this point) are
- It's inefficient
- There's not enough good guidance on not doing dumb things (ToArray etc being case in point).
EF does a helluva job converting LINQ to SQL so what would be interesting is if there was a preprocesser that went through the whole LINQ chain, worked out what was really happening, then optimised (ie not did a bunch of stuff, parallelised other stuff, vectorised some stuff etc) and made it more efficient than foreach loops (which themselves are not efficient).
We shouldn't have a million devs optimising the same code. We should be able to express the code in elegant syntax and have the tools do the optimisation.
cheers
Chris Maunder
|
|
|
|
|
Plain-old-for definitely will work too, but this "one-liner" is specially intended for simple cases, where "for" is just too much!
Say, you need just checked checkboxes:
var chs = AllChBoxes.Where(box => box.IsCheched);
...and now look what you have to do with for:
var chs = new List<CheckBox>();
foreach(var ch in AllChBoxes)
if (ch.IsChecked) chs.Add(ch);
You write THREE lines (what is obviously more to read + more error prone) and achieved... even worse result, since IEnumerable in one-liner takes less memory (if needed at all).
So get your a$$ from the criocamera and study new way!
|
|
|
|
|
Here it's still obvious. It's the chaining where things start to get confusing.
Besides, I can't agree with your statement that you must create a list, after all you need those checkboxes in order to do something with them, you can most of the time just do that in the very same loop that checks them.
|
|
|
|
|
You said "for vs LINQ", I show you obvious case where you're not right. If you wanna just discuss how long LINQ can be - it's different question.
You don't understand word "materialized". If you use "for", you have to create physical list, where you keep your objects. In case of LINQ you have Enumerator, which will not take any object until you ask! It's important difference when you have billion objects, where half of 'em match your query. Enumerator just pass 'em one-by-one (keeping memory consumption low exactly for ONE ELEMENT), while your "for" takes all necessary memory at once.
|
|
|
|
|
Thornik wrote: You said "for vs LINQ", I did not, I showed an example of what I deem unreasonable. Using a single clause is still clear, if often unnecessary, though I like Max for example - there's a case where it really is simpler than an equivalent explicit loop.
Thornik wrote: You don't understand word "materialized". If you use "for", you have to create physical list, where you keep your objects. Oh you mean the source, sure. foreach it is then, problem solved.
|
|
|
|
|
You shown long LINQ query and start talking about "foreach". But even being that long, FORMATTING RULES.
someStuff.Where(c => c != What)
.Select(d => d + The)
.Foreach(e => Hell(e));
Oh you mean the source, sure. foreach it is then, problem solved.
Nope. You do not solve problem if you prepare list of objects thru foreach - you have to put 'em in a List<> (because hell knows how it will be used later). In case of LINQ you prepare just REQUEST (which takes zero memory), which later will enumerate any amount of objects. And BTW same request can be enumerated many times.
|
|
|
|
|
Thornik wrote: because hell knows how it will be used later So then it isn't the source, and it probably doesn't need to exist. Just act on it right then and there in the loop.
|
|
|
|
|
Agreed, this is cancer. IEnumerable and Linq will cause far more instructions to be processed by the processor than a simple "for" loop with an "if". Will the average user notice this? No, not on todays computers. But as more people do these trick things, it does build up.
I remember when trick things were done to save processor clock ticks, and it was just as bad for reading code. The smart ones would document the clever code with comments with a reasoning why it had to be done.
if you've seen that in production code before, people are trying to be clever for clever sake, I just don't see the benefit.
|
|
|
|
|
In the same way people write crappy Transact SQL, crappy C#, and crappy documentation, some write "elegant" SQL, C#, LINQ, etc.
I found an "elegant" NEED for IEnumerable the other day; it simplified the code using it.
|
|
|
|
|
Yeah - I hate that sort of sh*t as well. Write-only programs. I think people think they're clever, or something: "Those of you who think you're intelligent are annoying to those of us who are"(tm)...
|
|
|
|
|
I agree with Harry here, but I think a lot of developers, including maybe even Harry, are missing the point.
Programming code is not there to suit the computer, or the compiler, or the run-time engine.
If it was, we would do everything in machine code, or p-code, or whatever.
Code is there to be read by PEOPLE.
Anything that obscures that intent is, basically, just pretentious BS.
Why should I have to stop and ponder your code for even 3 seconds? Every time I see that line?
|
|
|
|
|
I now have my son back. Last Christmas we finally gave in and bought our son an iPad. Since then we have become iPad widows. Nothing else interests him...until now that is. Pokemon go has got him off the iPad and onto the...iPhone. I know it doesn't sound like much...but it is. Leaving the house is so easy now, no arguments. Sometimes the signal goes and he is forced to talk about the interesting surroundings. And what's more, someone had the bright idea to make pubs pokestops a place where you get random gifts. Thanks Nintendo -bringing families back together again since 2016.
|
|
|
|
|
Just another experiment by the elite pushing towards a paradigm where all reality is augmented through technology, whether it is this or "google glass" or self driving cars, and government has the capacity to alter any information past present or future.
|
|
|
|
|
Oi who let you out of the soapbox?
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You define game developers as "the elite"?
I'm sure that there are one or two members here who might disagree with that.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You mean there are actually people who don't want to be considered "elite"?
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Their next game will be Children Go. You can find augmented children in and around your house who, contrary to your own, like to spend time with you
|
|
|
|