perf(tracing): use get_local_item instead of get_item #14404
Conversation
brettlangdon
added
the
changelog/no-changelog
|
|
Bootstrap import analysisComparison of import times between this PR and base. SummaryThe average import time from this PR is: 268 ± 3 ms. The average import time from base is: 269 ± 2 ms. The import time difference between this PR and base is: -1.3 ± 0.1 ms. Import time breakdownThe following import paths have shrunk:
|
Performance SLOsCandidate: LANGPLAT-642/optimize.start.finish.span (47c6646) 🔵 No Baseline Data (24 suites)🔵 coreapiscenario - 12/12 (2 unstable)🔵 No baseline data available for this suite
|
#14404 helped show that people should be clear/intentional over which core API is used for getting items off of an `ExecutionContext`. This PR aims to rename and update doc strings to try and clarify further what will happen when the function is called. - `get_item` -> `find_item`: since this API will traverse the context tree looking for the first value for the key. normally this adds the overhead of a loop instruction, but in general will return back quickly. The problem comes from cache misses where we traverse the whole tree just to return the default value. - `get_local_item` -> `get_item`: make it so any new usage of `get_item` does the more correct thing by default - `get_items` -> `find_items`: similar as `find_item`, making it more clear we iterate the whole context tree for each key Main open question still is, what should `__getitem__` do? this one is harder to refactor without knowing 100% of all usages of `ctx["key"]` in the codebase, so we should handle as a follow-up since it might have higher impact. Opinion: we should remove the `__getitem__` API and force people to use `get_item` or `find_item` for clarity.. the overhead should be the same since they are all Python function calls. ## Checklist - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) ## Reviewer Checklist - [ ] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)
core.get_item/ExecutionContext.get_itemwill search through the hierarchy of parents until it finds the key (or cache miss on all parents and returns the default).Most usage of context set_item/get_item are intended to be for the currently actively context only, and don't need to search for an item potentially on the parent.
When profiling
get_itemcan be up to 5-6x slower thanget_local_itemespecially for cache misses.This change updates the
ddtrace/_trace/trace_handlers.pyusage to only useget_local_iteminstead.Checklist
Reviewer Checklist