+972 52-548-6969
Optimizing read transaction startup timeEvery little bit helps, a LOT
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).
More posts in "Optimizing read transaction startup time" series:
- (31 Oct 2016) Racy data structures
- (28 Oct 2016) Every little bit helps, a LOT
- (26 Oct 2016) The performance triage
- (25 Oct 2016) Unicode ate my perf and all I got was
- (24 Oct 2016) Don’t ignore the context
- (21 Oct 2016) Getting frisky
- (20 Oct 2016) The low hanging fruit
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.
Yes, exactly: my point was just that by saying "eliminating the call" a reader might have misunderstand that for the "lambda call", where instead the cost was about the string formatting thing.
njy, There isn't actually a lambda call here. That is a property using lambda expression.
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 ?
Rémi, Look at previous posts about our attempts to reduce I/O costs. We have done quite a lot there, and we gotten to the point were we are hitting the hardware limits.
If you have a 100 Mbps network, there isn't a way for us to bypass that, etc. But we can reduce costs all around by reducing CPU / memory, etc.
Yep, that's what I said
Comment preview