debug-build-times

Diagnose slow venv builds caused by unnecessary native extension recompilation across riot runs.

650|546|Updated Jun 20, 2016
One-click install
npx skills add https://github.com/DataDog/dd-trace-py --skill debug-build-times
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debug-build-times
Source: https://github.com/DataDog/dd-trace-py/tree/main/.claude/skills/debug-build-times
Command: npx skills add https://github.com/DataDog/dd-trace-py --skill debug-build-times

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

CI base venv builds for dd-trace-py become slow when native extensions (CMake, Cython, Rust) are recompiled unnecessarily on warm runs, defeating the ext_cache mechanism. This Skill helps you pinpoint which extensions rebuild, why the cache is not restoring, and how to verify hash stability.

Core Features & Use Cases

  • Cold vs. warm build comparison: Runs a scripted two-pass build (cold then warm) and diffs per-extension timing metadata to expose unnecessary rebuilds.
  • Rebuild root-cause analysis: Guides inspection of skip conditions, source file mtimes versus extension mtimes, and ext_cache restore warnings.
  • Hash stability verification: Detects cases where setup.py ext_hashes produces different hashes between save and restore, silently disabling the cache.
  • Use Case: A CI base venv build that should take under 30 seconds warm is taking minutes; run the test script, inspect debug_ext_metadata_warm.txt, and identify the extension whose sources appear newer than the cached artifact.

Quick Start

Ask the assistant to run the build cache diagnostic script for Python 3.13 and analyze the cold and warm extension metadata to find which native extensions are rebuilding unnecessarily.

Frequently Asked Questions about debug-build-times

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose slow venv builds in dd-trace-py?

Run the test_venv_cache.sh script with your Python version to perform cold and warm builds, then compare the generated debug_ext_metadata files. Any extension showing more than 0.05 seconds on the warm run is rebuilding unnecessarily.

Why is ext_cache not saving time on warm builds?

The cache silently becomes a no-op when the venv Python version does not match the build Python, since ext_hashes computes targets with the running Python's suffix. It also fails when extension hashes change between save and restore, indicating a hash stability bug.

How do I find which native extension is rebuilding unnecessarily?

Enable phase timing with _DD_DEBUG_EXT=1 and inspect the warm metadata file for extensions exceeding 0.05 seconds. Then check the skip condition debug output and compare source file mtimes against the cached extension's mtime.

What is the expected build time for a warm venv build?

A warm run with extensions cached should complete pip install -e . in under 30 seconds, with the warm phase itself under 10 seconds. Cold builds typically take around 100 seconds.

Why does the ext_cache venv Python version need to match the build Python?

ext_cache.py uses sys.executable to call setup.py ext_hashes, which computes extension targets with the running Python's suffix such as cpython-313. A mismatched venv Python makes cache save and restore operate on the wrong suffix.