[SERVER-30761] Optimize parsing code for top-level MatchExpressions Created: 21/Aug/17 Updated: 30/Oct/23 Resolved: 17/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kyle Suarez | Assignee: | Blake Oler |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Query 2017-09-11, Query 2017-10-02, Query 2017-10-23 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 0 | ||||||||
| Description |
|
The MatchExpression parser has a giant if block that performs many string comparisons as it attempts to parse a top-level keyword. We should attempt to optimize this to reduce the number of string comparisons. A hash map seems like a better choice. |
| Comments |
| Comment by Githook User [ 17/Oct/17 ] |
|
Author: {'email': 'blake.oler@10gen.com', 'name': 'Blake Oler', 'username': 'BlakeIsBlake'}Message: |
| Comment by Tess Avitabile (Inactive) [ 06/Sep/17 ] |
|
Sure, I can pick this up. I might be tempted to do a larger cleanup of the MatchExpression parser, for example the inconsistent handling of operators that are only allowed at the top level ($where, $atomic/$isolated, $geoNear), and generally looking for bugs and seeing how I might make this easier to follow. |
| Comment by David Storch [ 06/Sep/17 ] |
|
tess.avitabile, do you have time to pick up this task? Expressive $lookup work definitely takes priority, but it seems you may be partially blocked on that at the moment. |