[SERVER-85325] Classify `OpCtx` decorations based on their performance cost Created: 17/Jan/24 Updated: 27/Jan/24 Resolved: 27/Jan/24 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Amirsaman Memaripour | Assignee: | Patrick Freed |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Service Arch 2024-01-22, Service Arch 2024-02-05 | ||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
The server makes a new OperationContext for each user operation. Instances of OperationContext are decorated, and making and destroying these decorations is expensive. This ticket should go over the list of all decorations on OperationContext and classify them into the following categories:
Once we have this list, we can target the second and third groups by:
|
| Comments |
| Comment by Patrick Freed [ 27/Jan/24 ] |
|
Tickets have been filed, closing this out. |
| Comment by Patrick Freed [ 22/Jan/24 ] |
|
I went and looked through the default constructors for all of OperationContexts decorations, and it doesn't look like any of them contain complex initialization logic. OperationTimeTrackerHolder 's constructor heap allocates an instance of a class that contains a mutex and a long, which could potentially be expensive if done on every operation, but other than that, the constructors are mostly just default and the member fields have simple or trivial constructors (e.g. integers, booleans, vectors, optionals). The one notable decoration is CurOpStack, which by size is far larger than any other decoration on OperationContext. In fact, according to this comment, it constitutes over half of the entire decoration buffer. Its constructor also involves an extra small heap allocation. It would seem that the best avenue for improvement here would be to reduce the size of CurOpStack, perhaps by delegating non-required parts of it to separate allocations that we only do on a subset of operations or just by moving some of its state elsewhere. I would be curious to see a flamegraph or some benchmarking results that point to OperationContext decorations as being a performance bottleneck, since my initial look into it suggests that they shouldn't be overly expensive. The one exception could be CurOpStack, though even that is basically just a 3.5kb allocation, which doesn't seem egregious. Here's the full list of decorations and some notes about them: Trivial constructors/destructors
Simple / "empty" constructors
Cheap but non-trivial/non-empty constructors
Potentially expensive constructors, could be made cheaper
|