Michael's Coding Spot
michaelscodingspot.com · Personal blog · on HN since 2018
Michael Shpilt, a .NET developer, writes about C# performance, memory leaks, caching, and choosing a .NET web tech stack.
What HN saysHN commenters cite it for its JSON serializer benchmarks and ORM performance comparisons, using it as a reference when discussing .NET Core library speed.
18HN people shared it
4linked it in comments
20stories submitted
121story points
2 years agolast shared
2018people per year2026
Most-shared posts
- 1The Battle of C# to JSON Serializers in .NET Core 33 people · 4 points · first shared 2019 · discussion on HN
- 2You Can Cause Memory Leaks in .Net2 people · 4 points · first shared 2019 · discussion on HN
- 3Where did the Microsoft tech stack disappear?1 people · 84 points · first shared 2018 · 144 comments on HN
- 45 Techniques to Avoid Memory Leaks by Events in C# .NET you should know1 people · 4 points · first shared 2018 · discussion on HN
- 5Tips to Become an Efficient, High-Performance Software Developer1 people · 3 points · first shared 2019 · discussion on HN
- 6Cache Implementations in C# .Net1 people · 3 points · first shared 2019 · 1 comments on HN
- 7New browser APIs to detect JavaScript performance problems in production1 people · 3 points · first shared 2021 · discussion on HN
- 8C# .NET Web Application Tech Stack: Choosing the Front End1 people · 2 points · first shared 2022 · discussion on HN
- 99 Must Decisions in Desktop Application Development for Windows1 people · 2 points · first shared 2018 · discussion on HN
- 1011 things I wish I could tell myself as a Junior Software Developer1 people · 2 points · first shared 2019 · discussion on HN
- 11Reasons for Startups to Choose Asp.net over Node.js1 people · 2 points · first shared 2022 · discussion on HN
- 1213 Things That Keep Us Motivated as Software Developers1 people · 1 points · first shared 2019 · discussion on HN
- 13C# Features: Innovations or Imitations? – Part 11 people · 1 points · first shared 2018 · discussion on HN
- 14Development slowness in big and legacy applications1 people · 1 points · first shared 2023 · discussion on HN
- 15My Christmas Wish List from Visual Studio and the C# Build System1 people · 1 points · first shared 2022 · discussion on HN
What HN people wrote when they linked it
0xcoffee · 2019-12-06
I would love to here some MSFT people who work on the Net Core teams thoughts about these libraries, because it seems the community has really amazing things to contribute, such as this string builder library.
Net Core has seen amazing improvements compared to Framework, yet often still falls behind existing community offerings.
e.g. UTF8JSon library: https://michaelscodingspot.com/the-battle-of-c-to-json-serializers-in-…
Outperforms the new Net Core json library.
HyperLinq:
https://medium.com/@antao.almada/netfabric-hyperlinq-zero-allocation-f…
Is basically Linq with 0 allocations.
What is blocking MS from integrating these approaches into Net Core?
ryanjshaw · 2024-04-01
Modern ORMs are pretty efficient [1]. Some developers use the ORM for the "write model" and native SQL for reads/reports, if you are read-heavy.
[1] https://michaelscodingspot.com/npgsql-dapper-efcore-performance/
Kwpolska · 2023-03-21
I Googled “.NET assembly loading”. The second hit is “Understanding How Assemblies Load in C# .NET”, [0], from July 2020, 4 months before the RTM release of the unified .NET 5. While this post mentions .NET Core by name once, this post is completely irrelevant to .NET Core/5+ (which threw out the Global Assembly Cache, assembly redirections, and generally simplified everything). How do you find articles that are actually relevant to the modern .NET and not the Framework?
The Java stuff is easy. From the perspective of a Java developer, most of the things you listed (except for ME, EE and JavaBeans) are just “Java”. And they always have been.
[0] https://michaelscodingspot.com/assemblies-load-in-dotnet/
Rapzid · 2020-03-08
Decoding JSON is surprisingly intensive. Check out this to see what's going on with it in Dotnet: https://michaelscodingspot.com/the-battle-of-c-to-json-serializers-in-… .
Node.js will have that issue and in fact the stdlib JSON encoding/decoding can't even be paused so once you start a processing something you're stuck until it's done. You could, however, write an incremental serializer/deserializer that could spread processing out across many event loop cycles to mitigate.
Go, ASP.NET, and others not so much, depending, because the schedulers can pause and resume the tasks(on top of being threaded).