Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance Tuning for .NET Core

reubenbond.github.io

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Performance Tuning for .NET Core

#31

Post by tluyben2 »

gameswithgo wrote: post #11

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: https://github.com/jackmott/LinqFaster

People abuse Linq a lot though; enormously complex queries over very large datasets without really knowing what you are doing. When people need .Each, some will just do .ToList().Each(. Etc. I found a bigger issue even with abuse/overuse) (or use at all really) of dynamic. I wish there was a way of to ban it at compile time.

Re: Performance Tuning for .NET Core

#32

Post by rhinoceraptor »

tluyben2 wrote: post #29
rhinoceraptor wrote: post #16

It 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/m…

The perf script from MS is what we use to profile and fix issues on linux. I do not have Windows; no issues so far with just Linux. We managed to diagnose and fix every perf issue so far. Not sure what you mean by windows only tools or manually generate symbols?

I haven't tried the script, the documentation says you need PerfView to view the data so I didn't bother running it.

For generating symbols, (I misspoke a bit, I mean downloading them) I'm talking about the native CLR runtime symbols. According to the docs if you want those, you need to use dotnet-symbol and manually download the symbols for the CLR alongside the CLR .so files.

Re: Performance Tuning for .NET Core

#33

Post by wvenable »

scarface74 wrote: post #14
wvenable wrote: post #8

Earlier quoted context omitted.

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

I understand the argument for composition-of-inheritance but they rarely apply when you actually need to do it. Often it's to reach in and fix a bug or enhance the behaviour of an existing component. You simply can't do that with composition.

Without inheritance (if the class is sealed) I often end up having to re-write the entire component or simply accept my fate. So that is a lose-lose situation.

Re: Performance Tuning for .NET Core

#34

Post by NicoJuicy »

rhinoceraptor wrote: post #32
tluyben2 wrote: post #29

Earlier quoted context omitted.

The perf script from MS is what we use to profile and fix issues on linux. I do not have Windows; no issues so far with just Linux. We managed to diagnose and fix every perf issue so far. Not sure what you mean by windows only tools or manually generate symbols?

I haven't tried the script, the documentation says you need PerfView to view the data so I didn't bother running it. For generating symbols, (I misspoke a bit, I mean downloading them) I'm talking about the native CLR runtime symbols. According to the docs if you want those, you need to use dotnet-symbol and manually download the symbols for the CLR alongside the CLR .so files.

Well, .net was for a long time only available on windows (since 2002 and development in late 1990's).

I think making the tools cross-platform after such a long time is not that easy/fast.

Re: Performance Tuning for .NET Core

#35

Post by gameswithgo »

GordonS wrote: post #13
gameswithgo wrote: post #11

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: 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'?

Yes it is more or less considered complete. I may do a pass over it to see if it can leverage or support span better sometime soon.

Performance deltas should be similar on .NET Core.

Re: Performance Tuning for .NET Core

#36

Post by scarface74 »

wvenable wrote: post #33
scarface74 wrote: post #14

Earlier quoted context omitted.

Instead of my rehashing the old arguments about inheritance.... http://developer-interview.com/p/oop-ood/what-are-advantages...

I understand the argument for composition-of-inheritance but they rarely apply when you actually need to do it. Often it's to reach in and fix a bug or enhance the behaviour of an existing component. You simply can't do that with composition. Without inheritance (if the class is sealed) I often end up having to re-write the entire component or simply accept my fate. So that is a lose-lose situation.

That's where delegation comes in. You wrap each public method of Foo in another class call MyFoo and then fix the one method you care about. With C# and R# it's a simple matter of:

Create a new class

Create a private variable:

private Foo _foo

Click on _foo

Resharper menu -> Generate Code -> create Delegating members.

Re: Performance Tuning for .NET Core

#37

Post by reubenbond »

gameswithgo wrote: post #11

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: https://github.com/jackmott/LinqFaster

I feel I need to clarify this - my post is aimed specifically at optimizing code for high performance. Many of those tips will reduce readability of the code, which may make it harder to determine its correctness.

I'm a big fan of LINQ and I use it in my own code, just not in the high-perf bits. LINQ is great for writing code which has "obviously no deficiencies" in terms of correctness. Without it your code may end up having "no obvious deficiencies".

I also like LinqFaster, LinqAF and these other libraries/tools which can make LINQ usable in more domains.

Re: Performance Tuning for .NET Core

#38

Post by benaadams »

maxxxxx wrote: post #21
GordonS wrote: post #7

> 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 have never inherited from a class from a library unless it was specifically designed that way. I think it's much better to aggregate. Makes me wonder: Can you add extension methods to sealed classes?

Yes; extension methods just operate over the public interface

Re: Performance Tuning for .NET Core

#39

Post by benaadams »

blinkingled wrote: post #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?

Size generally; you can aggressive inline it, but you'll likely be pulling in some chunky stuff for the throw. Push the throw out of line and your inline will be more trim.

Re: Performance Tuning for .NET Core

#40

Post by pjmlp »

chrisseaton wrote: post #27
pjmlp wrote: post #20

Earlier quoted context omitted.

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.

That sounds more like an argument to seal your classes, rather than for why the JIT doesn't, in addition to that, assume classes as sealed until proved otherwise. You're talking about the programming model, where I'm talking about the implementation.

Well, JIT heuristics end up being designed to live with the typical code patterns of the programming language.

In Java's case, since methods are virtual by default so with open classes a large majority of the code has a possible indirection, hence such optimizations.

Post reply on HN