[SERVER-76782] emplace the DecorationContainer into Decorable's allocation Created: 03/May/23 Updated: 17/Aug/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Service Arch
|
||||||||||||||||
| Sprint: | Service Arch 2023-05-15, Service Arch 2023-05-29, Service Arch 2023-06-12, Service Arch 2023-06-26, Service Arch 2023-07-10, Service Arch 2023-07-24, Service Arch 2023-08-07 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Perhaps Decorable can share a single allocation with its associated DecorationContainer. This would save an alloc/dealloc in every Decorable (I'm looking at you, OperationContext, and make accessing the decorations more cache-friendly. This could be done perhaps by defining overloads for its new & delete operators. |
| Comments |
| Comment by Billy Donahue [ 17/Aug/23 ] |
|
Won't be getting to this for now. Shelving it. |
| Comment by Billy Donahue [ 16/Jun/23 ] |
|
sorry for overwriting. Unintentional as I was trying to paste your comment in as the top of a reply. Thanks for reconstructing. |