Some of the performance work that I have been doing recently was complex, and then, some of it isn’t:

And its implementation:

And the optimized version:

And the result?

The really interesting thing is that we have an improvement that is about 3 times more than we would expect. Why is that?

We can see that we eliminated the ResouceName call, and saved all of that cost, but we have much lower cost overall, where did that come from?

This is something that we saw over and over again. The obvious answer is that we now do less allocations, so we have less GC work to do, which is true as far as it goes, but it is also true that when we are even slightly faster, things start to align more closely, and we get a chain reaction (slightly less work means more time process the actual requests, so we can get more done in less).

Comments

@Oren: probably just nitpicking, I know, but when you say "We can see that we eliminated the ResouceName call" are you referring to the lambda call? If that is the case it is probably not true since, although the syntax for expression-bodied members is the same as a normal lambda, in the end that would not be a lambda after all.

I'm 99% sure that the hidden cost is not the lambda-like thing, but the (implicit) usage of the new interpolated string (FormattableString class) that is causing the perf loss.

njy,
The first impl is actually just a property using the lambda syntax.
The issue is that it is using string.Format() under the cover, and it is called a lot.
We fixed this by setting this property once at the ctor, and then it always returns the same value, saving the memory allocation, the string format, etc.

Oren, RavenDB is a database so it does a lot of IO (network, disk). What is the reason you start doing these kind of optimizations ? Is it because you're at a point where it's very difficult to improve performance on IO or other stuff, or because you try to optimize everything and it's on your process to do all kind of optimizations ?