-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guid perf enhancements #20483
Comments
Sent in #20488 I guess when all the existing tests pass this is proof enough that it works or not? |
The tests failed with the service rejecting the request What exactly do you want to return and return on this code path? |
In that case, can we at least avoid allocating memory for each call by using the rent buffer approach? This is a hot path when using the processor. |
Which memory? We get a string that is converted into a Guid. Do you mean the Guid Array itself? Side note: Why is the lock token a string on the public API and not a guid? |
Pool rental for small arrays can be slower than allocation an array. I was planning to send in a PR to do OneOfList and OnOfArray which could be more beneficial than renting so small arrays. But already switching to internal Locktoken to avoid converting string to guid and vice versa would be good |
If there is no time pressure on this I'm happy to give it a try |
I very skeptic if it makes sense to rent and return the single array there honestly. I don't think it is worth the effort. I also looked at the receive path and tried to optimize a bit for the single message receive by creating a "frugal list"
but then I realized since we are always expecting But I sent this one to compensate :) |
Along the lines of the optimization that @danielmarbach made in #20427, we can optimize the lock renewal path in a similar way by renting an array for the Guid array.
Also, there are several locations where we convert the LockToken property on a Received message into a Guid. This can be avoided by just referencing the internal LockTokenGuid property.
Interestingly, there is a separate LockToken(singular) constant. It's possible that this could be used instead without needing an array at all, but we would need to test and confirm with the service team.@danielmarbach tested this out and the service doesn't accept it.The text was updated successfully, but these errors were encountered: