Fix for slow down with many setups on single mock#1111
Fix for slow down with many setups on single mock#1111stakx merged 5 commits intodevlooped:masterfrom CeesKaas:master
Conversation
…a duplicated expectation is added
There was a problem hiding this comment.
Hi @CeesKaas, thanks for your patience.
I do agree that we should do something about this problem. I've thought about it for a bit, and your solution indeed seems to be the easiest.
Just a couple of details that need your attention. Then this should be good to merge!
Co-authored-by: stakx <stakx@eml.cc>
This reverts commit d90d3b1.
| lock (this.setups) | ||
| { | ||
| this.setups.Clear(); | ||
| this.activeInvocationShapes.Clear(); |
There was a problem hiding this comment.
Just a remark for posteriority: in theory, we should also filter out removed setups in RemoveAllPropertyAccessorSetups. Not doing means that the first time a property setup is recreated after a call to mock.SetupAllProperties(), there may be a superfluous call to MarkOverriddenSetups. This is an edge case however, and the overhead of the additional MarkOverriddenSetups in this case is probably quite small, so let's just ignore this for now.
|
All good. Thanks for contributing, @CeesKaas! 🚀 |
I've played with the code a bit this morning and this change fixes the unittests I've added (at the cost of a bit of extra memory consumption and an extra operation always to save n operations in most cases)
fixes #1110