[SERVER-55057] Improvements to ComparisonMatchExpressions Created: 09/Mar/21 Updated: 29/Oct/23 Resolved: 23/Aug/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Performance, Querying |
| Affects Version/s: | None |
| Fix Version/s: | 5.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mathias Stearn | Assignee: | Bikash Chandra (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Backwards Compatibility: | Fully Compatible |
| Sprint: | QE 2021-08-23, QE 2021-09-06 |
| Participants: |
| Description |
|
There are some low-hanging-fruit optimizations available to ComparisonMatchExpression:
I'm attaching a patch which addresses all of these. I saw a huge improvement in perf with this patch vs without. I also tried templating ComparisonMatchExpression::matchesSingleElement as matchesSingleElementImpl<MatchType> and calling it from each of the subclasses' matchesSingleElement() so that all of the branching on matchType() would compile away, but I didn't see any improvement in my workload, so I didn't include it in this patch. It is possible that workloads involving more than one MatchType would see some benefit, so it may be worth exploring in the future. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 23/Aug/21 ] |
|
Author: {'name': 'Bikash Chandra', 'email': 'bikash.chandra@Bikashs-MacBook-Pro.local'}Message: |
| Comment by Rushan Chen [ 22/Jul/21 ] |
|
For Bikash. |