Hacker News Reader

Comment by profquail | Hacker News Reader

I don't think that's necessarily enough to overcome the huge amount of work that has gone into making the JVM JIT fast code and giving it a world-class garbage collector.

The CLR doesn't have a well-tuned JIT compiler and a fast garbage collector? Give .NET 4.5 a try -- it included some improvements to the garbage collector that were quite well-received (and the JIT was already quite good from .NET 4).

View on HN

I didn't say that the CLR's collector is bad, I just said I doubt that MS has put enough energy into it to compete on an even footing with the technologies being used on the JVM.

Last I checked the JVM is more aggressive about inlining, can do escape analysis on reference types, and has a more scalable parallel collector. There are also alternative JVMs that go even further - Azul has a theoretically pauseless collector, which is certainly not something .NET offers (though pause times are pretty short for gen 1/2 collections, at least!)

The lack of aggressive inlining in many scenarios is arguably a big issue for .NET due to the more pervasive use of IEnumerable and properties, both of which add the overhead of additional method calls. In particular, when those additional method calls don't get inlined and you're passing structs around, each one involves a full copy of your struct, because the people designing the standard library didn't use 'ref' anywhere.

Simple properties are nearly always inlined, in my experience. But you're generally right about IEnumerable, for which the biggest culprit is LINQ. The problem is that the JIT doesn't inline across code which is referenced through a delegate, even though the actual method being invoked is the same each time. So code like "foo.Select(x => f1(x)).Where(x => f2(x)).Etc()" ends up making two function calls for every element in foo.

> So code like "foo.Select(x => f1(x)).Where(x => f2(x)).Etc()" ends up making two function calls for every element in foo.

Which is okay because Linq queries are easily refactored into proper classes and methods.

Make it fast then make it fast.

You're right. But honestly I'd like to see these improvements trickle down to Mono. There's 2 things big things that combined could change this trend - (1) performance enhancements like this for Mono and (2) a lot of work being done on MonoDevelop.

I've been doing my part to work on #2. I've sent in some improvements to VI mode (https://github.com/mono/monodevelop/pull/247) because I think it's critical to convince myself to work in MD. It also needs a lot of work on the debugger end. If we can successfully get people to work on Linux, C# might actually become prevalent.

Reply on news.ycombinator.com