One of the tips is to avoid Linq, which many .NET developers are hesitant to do. I made a library that lets you use Linq style convenience functions without a performance hit in many cases:
Performance Tuning for .NET Core
11–20 of 78 posts
Re: Performance Tuning for .NET Core
#12> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
How do you know it's not been done for a good reason? Designing classes for extensibility is not easy. Furthermore, you can make classes extensible later on, but you can't do the reverse without breaking the API.
Sometimes yes - what I'm saying is that it shouldn't be the default, and all too often is, for no good reason, even in classes that would appear to be natural extensibility points.
On the plus side, when I encounter this, I generally ask the author on GitHub if it can be 'unsealed', and they generally do so.
Re: Performance Tuning for .NET Core
#13One of the tips is to avoid Linq, which many .NET developers are hesitant to do. I made a library that lets you use Linq style convenience functions without a performance hit in many cases: https://github.com/jackmott/LinqFaster
This looks really interesting - are the benchmarks in the GitHub repo against .NET Framework? With all the performance work that's been done in .NET Core, it might be interesting to compare it with .NET Core.
Also, I noticed there haven't been any commits for a while - is this more or less considered 'complete'?
Re: Performance Tuning for .NET Core
#14> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
I had the same thought when I saw that. There seems to be a trend to seal and lock down classes preventing any kind of extension. It sort of misses one of the main benefits of OOP and I know what I'm doing.
Instead of my rehashing the old arguments about inheritance....
http://developer-interview.com/p/oop-ood/what-are-advantages...
Re: Performance Tuning for .NET Core
#15> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
Why doesn't the JIT assume classes are effectively sealed until it sees a subclass, like the JVM does.
Re: Performance Tuning for .NET Core
#16It would be nice if .NET Core profiling was a bit easier on Linux, Microsoft has a shell script[1] to do profiling but it requires Windows only tools.
They don't ship Crossgen with the Linux packages, and you have to manually generate the .NET runtime symbols.
I've gotten things like FlameGraphs working using BCC profile[2], but it took quite a bit of work.
[1]: https://raw.githubusercontent.com/dotnet/corefx-tools/master... [2]: https://github.com/iovisor/bcc/blob/master/tools/profile.py
Re: Performance Tuning for .NET Core
#17> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
It is a general design principle for .net libraries that you should seal a class unless you deliberately and carefully design it to be extensible.
If a class is unsealed you are basically not able to change it ever again, since someone might have subclassed it and depend on all kinds of internal behavior. So it should only be done very deliberately.
Re: Performance Tuning for .NET Core
#18> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
Please yes!
Classes should be designed for extension on purpose, not as oversight, one of the SOLID pillars.
Taking advantage of an oversight is an open door for fragile base class problems and hard to track down bugs.
Re: Performance Tuning for .NET Core
#19> JIT won't inline functions that throw
Seriously? Never had to worry about that in Java land. What would be the reason for this?
Re: Performance Tuning for .NET Core
#20> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
Why doesn't the JIT assume classes are effectively sealed until it sees a subclass, like the JVM does.
Because it is bad design known as fragile base class, which usually leads to hard to track down bugs, because someone somewhere is accessing methods or internal class data structures that they shouldn't have to in first place.