[SERVER-77417] Reduce overhead of collecting operation CPU time Created: 24/May/23 Updated: 09/Jun/23 Resolved: 09/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Louis Williams |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Sprint: | Execution Team 2023-05-29, Execution Team 2023-06-12 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 145 | ||||||||||||||||
| Description |
|
The actual CPU time retrieval should not be very expensive. Investigate performance improvements in the OperationCPUTimers class, which is responsible for holding CPU timers. |
| Comments |
| Comment by Josef Ahmad [ 09/Jun/23 ] |
|
gregory.noma@mongodb.com good point. I've filed |
| Comment by Gregory Noma [ 09/Jun/23 ] |
|
josef.ahmad@mongodb.com would it be useful to still have the benchmarks that that patch had added? If so, we could file a new ticket just for the benchmarks? |
| Comment by Josef Ahmad [ 09/Jun/23 ] |
|
Closing as Won't Do, as we weren't sure about the value of this optimisation in the first place, and it's been identified as a source of regressions in some corner cases. |
| Comment by Githook User [ 09/Jun/23 ] |
|
Author: {'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}Message: Revert " This reverts commit 7b91e7bcb31ced28b7a862a2b729211092fe7f14. |
| Comment by Josef Ahmad [ 09/Jun/23 ] |
|
We decided to revert this ticket. While it sped up the CPU time collection by a low margin – only noticeable in microbenchmarks – it made the worst-case complexity quadratic. |
| Comment by Githook User [ 02/Jun/23 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: |
| Comment by Louis Williams [ 24/May/23 ] |
|
I did some profiling locally and it takes about ~360 ns to start() and stop() the CPU timer. If I include the entire lifecycle of creating an OperationContext, creating a timer, calling start() and stop(), and the destruction of everything, that goes up to 1 microsecond. I think one improvement we could make is to defer the destruction of timers until the OperationContext destroys all of its decorations, which happens out-of-line with the command path. |