4 ms·

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

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).

kevingadd 14y ago
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.
- CurtHagenlocher 14y ago
  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.
  - noblethrasher 14y ago
    > 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.
tkellogg 14y ago
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 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.

kevingadd 14y ago

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.

CurtHagenlocher 14y ago
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.
- noblethrasher 14y ago
  > 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.

tkellogg 14y ago

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 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.