> it's definitely nice that someone is finally pursuing reducing allocations (big enemy of GC / performance!). Now's the time to get in on the API design stage!
As an aside, I'd love to be able to stack allocate in .NET. I realize there are huge complications with doing this, but there are just so many short lived objects that I'd love to control the lifetime of.
Of course part of the problem is that in all the .NET libraries everyone news objects willy nilly, so it would likely require making a "stack alloc clean" library from scratch, so there wouldn't be much immediate benefit.
This is something that other GC languages like the Oberon family or Modula-3 get right, by default you use the stack unless the objects are NEWed.
Eiffel has it even better, you can declared if a class should be heap or value type (expanded in Eiffel speak) by default, but you get to override it when declaring variables.
Still you get this problem even in languages like C, if the developers went a bit too heap friendly.
That's crazy! I always thought objects were stack allocated by default unless escape analysis showed them to escape the function return. Goes to show how little I know about .Net memory allocation..
Could you elaborate on what the problems would be with storing on the stack? I'm oblivious to what the problem would be. Stack relocation?
AFAIK no .net JIT does do escape analysis, at all. It's less of a problem than you might think because value types are allocated on the stack anyways.
no escape analysis in .NET, yet, it is coming.
I wouldn't hold out too much hope. Java always intended for escape analysis to remove the need for value types. Now they're adding value types.
You might like this series
You can stackalloc in .net. the very library I am writing in the article uses it for things like 32byte temp hashes etc. Var a = stackalloc byte; for instance
It's been a massive jump forward in my high performance low allocation .net code
All this streams stuff is still a bit pie-in-the-sky; it's definitely nice that someone is finally pursuing reducing allocations (big enemy of GC / performance!). Now's the time to get in on the API design stage!
You can catch some things like this on Github's trending C# page, where 5 stars in one day is often enough to make the list. It's unfortunate some of the main .NET core repos wind up soaking up so many spots there; very few non-MS employees are paying that much attention to them on a day-to-day basis.
Part 2: A faster lower allocation stream stack wielded for ALPN/TLS and… HTTP2
Part 3: The journey continues to Secure Pipelines, via OpenSsl
Marc Gravell had a good post on Channels/Pipelines too:
This is a key part of the .NET roadmap to speed up the basic data pipeline workload of most apps:
http://tattoocoder.com/aspnet-slack-sign-up/ is one Slack which has been suggested to me which is frequented by the ".NET crew". Booyah.
Cool that you spoke to these guys in chat. Where do they hang out? I've only really seen interaction in GitHub comments, which doesn't really suit the sort of water cooler conversations you describe (and you really need in a large project).
.NET v1.0 was released in Feb 2002. I'm not sure 15 years is enough time to attribute something to your granddad.
"It turns out that while Orleans is very cool in the performance and latency sensitive tasks I had in mind it wasn’t suited to what I wanted. My interfaces were too chatty and sometimes in large math models mutable state is the only way to get things done quickly."
Shit like this really pisses me off
Was hoping for an article on some previously undiscovered Perl-style pipe syntax in .NET. Severely disappointed. This is a relatively contentless post.