chore(internal): remove time functions from compat module

[vitor-de-araujo]

This PR removes 4 time-related functions from ddtrace.internal.compat that existed for compatibility with Python < 3.7, and replaces all uses with the corresponding functions from the builtin time module: time_ns, monotonic, monotonic_ns, process_time_ns.

The original motivation for this was noticing that the fallback code for time_ns had the wrong multiplier, and then checking that we don't really need these functions anymore, as we only support Python >= 3.7.

Checklist

• 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
• The change includes or references documentation updates if necessary
• Backport labels are set (if applicable)

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 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

[github-actions]

CODEOWNERS have been resolved as:

benchmarks/rate_limiter/scenario.py                                     @DataDog/apm-core-python
ddtrace/_trace/span.py                                                  @DataDog/apm-sdk-api-python
ddtrace/contrib/internal/botocore/services/kinesis.py                   @DataDog/apm-core-python @DataDog/apm-idm-python
ddtrace/contrib/internal/kafka/patch.py                                 @DataDog/apm-core-python @DataDog/apm-idm-python
ddtrace/debugging/_debugger.py                                          @DataDog/debugger-python
ddtrace/internal/compat.py                                              @DataDog/python-guild @DataDog/apm-core-python
ddtrace/internal/opentelemetry/span.py                                  @DataDog/apm-sdk-api-python
ddtrace/internal/rate_limiter.py                                        @DataDog/apm-core-python
ddtrace/internal/utils/time.py                                          @DataDog/apm-core-python
ddtrace/profiling/collector/_lock.py                                    @DataDog/profiling-python
ddtrace/profiling/collector/memalloc.py                                 @DataDog/profiling-python
ddtrace/profiling/collector/stack.pyx                                   @DataDog/profiling-python
ddtrace/profiling/event.py                                              @DataDog/profiling-python
ddtrace/profiling/scheduler.py                                          @DataDog/profiling-python
tests/debugging/mocking.py                                              @DataDog/debugger-python
tests/integration/test_sampling.py                                      @DataDog/apm-core-python
tests/profiling/exporter/test_http.py                                   @DataDog/profiling-python
tests/profiling/test_accuracy.py                                        @DataDog/profiling-python
tests/profiling/test_scheduler.py                                       @DataDog/profiling-python
tests/submod/stuff.py                                                   @DataDog/apm-core-python
tests/tracer/test_rate_limiter.py                                       @DataDog/apm-sdk-api-python

[vitor-de-araujo]

Is this correct? time.time_ns() will only be evaluated once at module load time, not every time the constructor is called.

[P403n1x87]

Good shout. This shouldn't be a big issue because generally the profiler is a singleton and it is booted at start-up. The same kinda applies to tests (modulo a few delays perhaps). However, definitely something to keep in mind, just in case.

[datadog-dd-trace-py-rkomorn]

Datadog Report

Branch report: vitor-de-araujo/remove-compat-time-ns
Commit report: 7baae74
Test service: dd-trace-py

✅ 0 Failed, 592 Passed, 694 Skipped, 20m 22.47s Total duration (16m 50.74s time saved)

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-09-30 11:15:11

Comparing candidate commit 7baae74 in PR branch vitor-de-araujo/remove-compat-time-ns with baseline commit 7e8eb0b in branch main.

Found 7 performance improvements and 0 performance regressions! Performance is the same for 268 metrics, 53 unstable metrics.

scenario:iast_aspects-aspect_iast_do_lower

• 🟩 max_rss_usage [-2.850MB; -2.484MB] or [-9.752%; -8.502%]

scenario:iast_aspects-aspect_iast_do_lstrip

• 🟩 max_rss_usage [-2.891MB; -2.525MB] or [-9.862%; -8.614%]

scenario:iast_aspects-aspect_iast_do_modulo

• 🟩 max_rss_usage [-2.893MB; -2.542MB] or [-9.872%; -8.673%]

scenario:iast_aspects-aspect_iast_do_repr

• 🟩 max_rss_usage [-2.777MB; -2.474MB] or [-9.472%; -8.438%]

scenario:iast_aspects-aspect_iast_do_str

• 🟩 max_rss_usage [-2.852MB; -2.569MB] or [-9.717%; -8.753%]

scenario:iast_aspects-aspect_iast_do_title

• 🟩 max_rss_usage [-2.686MB; -2.380MB] or [-9.185%; -8.136%]

scenario:iast_aspects-aspect_iast_do_upper

• 🟩 max_rss_usage [-2.855MB; -2.548MB] or [-9.730%; -8.684%]

[P403n1x87]

Would we save much if we imported monotonic_ns and called it directly, instead of every time looking it up from the time module?

[vitor-de-araujo]

Is this something we should do just here, or on every place using monotonic_ns, or on every place using any of these functions?