[–] com2kid link

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


[–] pjmlp link

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.


[–] nothrabannosir link

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?


[–] thomasz link

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.


[–] jackmott link

no escape analysis in .NET, yet, it is coming. set


[–] moomin link

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.


[–] drawaes link

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[32]; for instance


[–] drawaes link

It's been a massive jump forward in my high performance low allocation .net code


[–] j_s link

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



[–] manigandham link

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:




[–] nstj link

http://tattoocoder.com/aspnet-slack-sign-up/ is one Slack which has been suggested to me which is frequented by the ".NET crew". Booyah.


[–] topbanana link

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


[–] ourmandave link

.NET v1.0 was released in Feb 2002. I'm not sure 15 years is enough time to attribute something to your granddad.

If it was javascript, then it would "not your forefather's".


[–] Allower link

"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


[–] debacle link

Was hoping for an article on some previously undiscovered Perl-style pipe syntax in .NET. Severely disappointed. This is a relatively contentless post.