2 ms·
Yes, but how many C# projects ever need that scale? If it's an internal enterprise app, the bread and butter of C# apps, it's a totally useless optimization. It
by mattmanser 11y ago
Yes, but how many C# projects ever need that scale? If it's an internal enterprise app, the bread and butter of C# apps, it's a totally useless optimization. It wouldn't reduce the size at all.
The kind of web scale business that should be using async, let's be frank, those kind of projects don't use C#. Go look at the YC list of technology, not a single C# user on there.
If that's all you the benefit of using async is, it hopefully looks like I'm ok not using it.
- tracker1 11y agoBut even in the enterprise responsiveness is appreciated... if you're making multiple calls on the backend... resource authentication, related item lookup, and other services, if you can run all of these requests asynchronously, then it's the max of those items plus a little overhead for conjunction... not using async is the aggregate... it's the difference between a sub-100ms response, or over... 100ms is nearly transparent, more than that is not. I don't disagree that it isn't that much of a benefit in many cases, but tbh if I'm to chose between async usage and, for example ever seeing EntLib Data classes, or a DI/IoC tool when no testing is being done, I'll take async. There are plenty of practices in C#/.Net shops that are just hideous to work with, async imho isn't one of them.