3 ms·

Agree with all. But if 80% of your code can be performant with "ideomatic' code, 15% needing a bit more attention (such as not making use of certain abstraction

Agree with all. But if 80% of your code can be performant with "ideomatic' code, 15% needing a bit more attention (such as not making use of certain abstractions, like link-to-objects, etc.), with the other 5% requiring diligent attention (Span, etc.) - then your making gradual perf gains as you wish, all within the same language, runtime, and memory pool. This is much better than a re-write and dealing with FFI, or just as likely, full-on serialization between your old code and Rust code. With that said, there isn't much of an excuse for non-0-cost enumerators, etc. -- given that refactoring tools switch between foreach, linq, indexing or ptr/spanning, you'd think the compiler-chain or jitter could do the same. Roslyn is a better back-end for meta-programming, but it's too bad MS denies us the benefits of surfacing meta-programming to the language or at least tool level, or we'd have tools that could easily convert linq to highly optimized code. You could also have compiler-enforced "levels" of C# code that had restricted features/semantics, such as "alloc-free", etc. - right now the choice is just "default" or "unsafe".

bob1029 6y ago
I think having a mode where LOH allocations are treated as a runtime exception (i.e. with a helpful exception message pointing to the offending object type) could help to guide developers down this path really well. Something like: "LOH allocation detected for object 'MyNamespace.MyObject'. Attempted allocation bytes: 90K (maximum 85,000 bytes)." Then one level up from that restriction would be the totally alloc-free approach you mention which could potentially mean the GC could be put into a special idle/framework-only mode. For alloc-free, I believe you could enforce this at compile time, as opposed to run-time for the LOH condition.
- DaiPlusPlus 6y ago
  Alloc-free would be nice if the CLR/CLI supported it, but I understand there’s too many major architectural changes required, e.g. to allow class object instances to live in the stack and limit their lifetime to prevent an invalid object reference. Even today you can’t `stackalloc` an array unless you’re using `unsafe`.

bob1029 6y ago

I think having a mode where LOH allocations are treated as a runtime exception (i.e. with a helpful exception message pointing to the offending object type) could help to guide developers down this path really well. Something like: "LOH allocation detected for object 'MyNamespace.MyObject'. Attempted allocation bytes: 90K (maximum 85,000 bytes)." Then one level up from that restriction would be the totally alloc-free approach you mention which could potentially mean the GC could be put into a special idle/framework-only mode. For alloc-free, I believe you could enforce this at compile time, as opposed to run-time for the LOH condition.

DaiPlusPlus 6y ago
Alloc-free would be nice if the CLR/CLI supported it, but I understand there’s too many major architectural changes required, e.g. to allow class object instances to live in the stack and limit their lifetime to prevent an invalid object reference. Even today you can’t `stackalloc` an array unless you’re using `unsafe`.