Shouldn't that while loop @1:26 translate to something like again: if(something) dostuff i++ goto again; ? Now it (@1:31) looks more like do while Anyway, good stuff. Thanks.
Yes, this is all great stuff to know, but I don't think it's good to know for optimization reasons. If my manager told me that code chunk he showed at 33:35 was too slow or used too much memory I'd look at him concerned and then I'd profile it before doing any analysis about what the compiler is doing.
I mean.. C# *is* used for some high-performance stuff, like in unity for games or other desktop workloads. Knowing which abstractions are cheap and which ones create their own classes and statemeachines (omg) I think is really good so you don't accidentally use them in hot paths.
Comrade Stinger the state machine isn’t the problem, that’s equivalent to an int state and a switch. The problem is, that it needs a class, and everything that allocates can trigger a „whole world stops GC sweep“
@@slavaknyazev45 I feel like the speaker's ordering of topics was off. He should look into reformatting his talk to make it more intuitive and flowing. I had to watch this 3 times and then I got the entire thing.
I just want to add that the talk was very informative if you give it some time. The Sharplab demo was really cool as well. I think he should have used that in the beginning to make the intent of the video pop.
at offset 1:17 David blandly hops from foreach to for but this forgets that the foreach is IEnumerable and you DON'T know the count in advance, and there is no indexor so listOfInts[i] typically won't work (cf ICollection, etc) unless that sut is [say] an array. That jarred when I viewed this bit but I persisted to the end and he covers some good stuff later so hang in there!
I highly doubt that he "forgot." Is far more likely, based on his experience and the name of his variable, that he simply took the IList interface for granted here. Blindly performing the transformation on something that is only known to be of IEnumerable would indeed be silly but it is perfectly sane to rely on the ICollection contract that IList commits to.
Actually, depending on the type, the compiler will optimize a foreach loop to a for loop. Eg. in case of int[], it won't actually use an IEnumerator, and instead use pure IL instructions to iterate the array.
Those examples weren't supposed to be real, just trying to show the concept of lowering, but I appreciate the feedback and if I deliver the talk again I'll try to make that clearer.
This guy was awesome, good presentation, clear talking and interesting subject.
Good presentation. I like the simplistic approach.
Amazingly insightful talk.
excellent talk!
Great stuff
Enumerator: Removing items from the list (from inside the loop) will make MoveNext() return/set a false Current()-Item?!
Was the compiler mentioned that this talk referenced? There are many C# compilers and they operate differently.
At 36:00, he links to roslyn, which is the C# compiler that he used.
Shouldn't that while loop @1:26 translate to something like again: if(something) dostuff i++ goto again; ?
Now it (@1:31) looks more like do while
Anyway, good stuff. Thanks.
Gold, many thanks!
Why there will be a stackoverflow exception in c#4's foreach ?
I believe he was referring to the website stackoverflow, because there were a LOT of questions about this behavior when C#4 came out.
18:28 (e as IDisposable)?.Dispose();
Not in the code he has shown, bc that was C# 4. Null-conditional operators are only after C# 6
Ah, your code is before lowering. 😀
If you are concerned about performance to this low level, then C# is the wrong tool for the job. Go use C++, C, Rust...
Yes, this is all great stuff to know, but I don't think it's good to know for optimization reasons. If my manager told me that code chunk he showed at 33:35 was too slow or used too much memory I'd look at him concerned and then I'd profile it before doing any analysis about what the compiler is doing.
I am just concerned how my code really works.
I mean.. C# *is* used for some high-performance stuff, like in unity for games or other desktop workloads.
Knowing which abstractions are cheap and which ones create their own classes and statemeachines (omg) I think is really good so you don't accidentally use them in hot paths.
Comrade Stinger the state machine isn’t the problem, that’s equivalent to an int state and a switch.
The problem is, that it needs a class, and everything that allocates can trigger a „whole world stops GC sweep“
@@comradestinger C#? Well that explains why unity's performance is so famously bad.
dead boring but useful. D:
Very Confusing and unclear :(
which part?
@@slavaknyazev45 I feel like the speaker's ordering of topics was off. He should look into reformatting his talk to make it more intuitive and flowing. I had to watch this 3 times and then I got the entire thing.
I just want to add that the talk was very informative if you give it some time. The Sharplab demo was really cool as well. I think he should have used that in the beginning to make the intent of the video pop.
He is confused
at offset 1:17 David blandly hops from foreach to for but this forgets that the foreach is IEnumerable and you DON'T know the count in advance, and there is no indexor so listOfInts[i] typically won't work (cf ICollection, etc) unless that sut is [say] an array. That jarred when I viewed this bit but I persisted to the end and he covers some good stuff later so hang in there!
I highly doubt that he "forgot." Is far more likely, based on his experience and the name of his variable, that he simply took the IList interface for granted here. Blindly performing the transformation on something that is only known to be of IEnumerable would indeed be silly but it is perfectly sane to rely on the ICollection contract that IList commits to.
Actually, depending on the type, the compiler will optimize a foreach loop to a for loop. Eg. in case of int[], it won't actually use an IEnumerator, and instead use pure IL instructions to iterate the array.
Those examples weren't supposed to be real, just trying to show the concept of lowering, but I appreciate the feedback and if I deliver the talk again I'll try to make that clearer.