Implement a CodeTimer stack #4518
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `orderMap` field was removed as it was only responsible for maintaining the insertion order of timer IDs. This is now accomplished more cheaply by changing `timeMap` to `LinkedHashMap<>`. This saves some extra hash table reads and writes, and also means we don't need to explicitly sort IDs during reporting. There were a couple places where we did redundant key lookups on `timeMap`, to handle cases where the key may or may not already exist. These were modified to instead do a single key lookup, via `computeIfAbsent()` and `get()`.
This is inspired by loggers, though based on `String.format()`. It allows using timers with dynamic names without needing to clutter calling code with `CodeTimer.isEnabled()` checks to avoid the overhead when not needed. The few places that used `CodeTimer.isEnabled()` for this purpose have been updated to use the parameterized form, and `isEnabled()` is now only used to check if timings should be reported.
Each thread has a stack of `CodeTimer`, with the top of the stack being available anywhere via a call to `CodeTimer.get()`. When a different timer is needed for a section of code, `CodeTimer.using()` will push a new timer onto the stack, and pop it off the stack when the timed code completes, restoring the previous timer. `CodeTimer.using()` also takes care of enabling the new timer based on `AppState.isCollectProfilingData()`, and reporting the results at the end if the timer is enabled. This saves some repeated logic and adds a bit of consistency in how timers are used.
All affected components followed the same basic pattern, with some variations: 1. Create the timer. 2. Enable / disable the timer, usually based on AppState. 3. Set a minimum threshold. 4. At the end, report to the profiling frame. Now (1), (2) and (4) are done automatically and consistently in `CodeTimer.using()`, with (2) and (3) also doable by the caller to customize the timer as needed.
cwisniew
approved these changes
Dec 7, 2023
cwisniew
approved these changes
Dec 7, 2023
cwisniew
added
the
code-maintenance
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Identify the Bug or Feature request
implements #4514
Description of the Change
A new per-thread stack of
CodeTimeris available to allow getting aCodeTimerfrom anywhere. The top of the stack is always available by calling theCodeTimer.get()static method. When a section of code needs to be timed with a report,CodeTimer.using(name, callback)is used. This method creates a new timer, enables it if necessary, pushes it onto the stack, runs the callback, pops the timer back off the stack, and generates a report. In other words, it runs the callback during which a new timer is available viaCodeTimer.get(), then reports the results.Additional changes include cleaning up
CodeTimerby removing unused bits, making thestart()/stop()methods leaner in terms of itsHashMap<>usage, and allowing dynamic IDs to clean up some calling code.I would advise ignoring whitespace in the diff, as the use of
CodeTimer.using()has modified the indentation of the code.Possible Drawbacks
Should be none.
Documentation Notes
N/A
Release Notes
This change is