Hacker News Reader

Comment by mwsherman | Hacker News Reader

Looks nice. A lot of people don’t realize how expensive Linq can be. That said, my preference for most (source) codegen is in the editor – this would be nice as an editor plugin.

View on HN

Oh, and a question – is the generated code actually semantically identical? For most uses practical uses, it is, but I think under racy conditions it could give different results.

It is, for the example. But it only works because it is known at that point that the input is not just an IEnumerable<int>, but rather an int[]. Knowing that they can generate a for loop, which is quite a bit faster than the enumerator. For an unknown IEnumerable they can still emit the loop and static helper method and cut down on the generated closure, but they cannot remove the IEnumerator usage. They could probably do the same as for the array if it's known that the source IEnumerable is a List<T> (and not a subclass, because GetEnumerator may have been overridden with side-effects).

Effectively this transformation is the same as doing "Convert LINQ to code" and "Extract method" in R# (although those tend to sometimes be unable to codify even simple LINQ expressions).

>It is, for the example.

It doesn't even look right for the example. This line:

    num += num2 + 3;

Should be:

    num += _linqitems[i] + 3;

Yeah, what the hell? That wont even compile. Is this thing even real? Why wouldn't the just use the actual output of their tool?

It's just a typo on the README and it's been fixed now.

The tool works fine, I've tried it out myself

Ok, good. A thing like that doesn't inspire confidence, but presumably it was just a typo then.

They probably manually inlined a line like

    int num2 = _linqitems[i];

from the decompiled output. I'm fairly certain that if the transformation wouldn't result in compiling code, the compiler would refuse to compile it, resulting in no assembly to decompile. They also noted somewhere to have run the System.Linq tests and only one edge case involving Min/Max and NaN failed. Tests likely wouldn't run either if the code didn't compile.

It's true, but 95% of the cases you get much better results by using the right data structures (dictionaries) instead of transforming queries to loops. Still is a very cool thing, hopefully is standardized into Roslyn

How would the provided example be better realized as a dictionary?

All true, but the example is a demo that doesn't do anything useful, and not typical code.

Using the best structure is a good idea but simple LINQ is very readable if performance isn't a big concern.

BTW I cover this in my recent book: https://www.packtpub.com/mapt/book/Application%20Development...

You could try code samples and benchmarks: https://github.com/PacktPublishing/ASP.NET-Core-1.0-High-Per...

Reply on news.ycombinator.com