Skip to content

chore: remove lazy loading to demonstrate regression - #17690

Closed
hebaalazzeh wants to merge 3 commits into
test-lazy-modules-basefrom
test-lazy-modules-regression
Closed

chore: remove lazy loading to demonstrate regression#17690
hebaalazzeh wants to merge 3 commits into
test-lazy-modules-basefrom
test-lazy-modules-regression

Conversation

@hebaalazzeh

Copy link
Copy Markdown
Contributor

This PR is a demonstration to verify that the CI import-profiler correctly catches performance regressions.

It was opened against the test-lazy-modules-base branch, which simulates a package with fast, lazy-loaded imports (0ms). In this PR, I have restored the 4,300 lines of heavy static imports to google-cloud-compute/init.py.

This effectively simulates the scenario where a PR "removes" lazy loading from a package, causing a massive latency regression. The CI import-profiler check should flag this regression and fail the presubmit, as requested by reviewers.

@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

hebaalazzeh added a commit that referenced this pull request Jul 14, 2026
## Overview
This PR integrates the import profiler script (introduced in #17467)
into our automated CI pipeline.

Why this matters: Import times significantly impact CLI responsiveness
and cold starts for Serverless products like Cloud Run and Cloud
Functions. Ideally, library imports should stay under 500ms, and
anything taking over 1 second is a target for optimization. This CI
check helps us proactively track metrics like import latency, memory
footprint, and code volume to prevent performance regressions on
critical libraries.

The primary goal of this check is to track and enforce performance
standards for package import times across the repository, especially
following our recent work on lazy loading and cold-start optimizations.

By running this benchmark as a CI check with a defined dynamic
differential failure threshold, we can programmatically prevent latency
regressions in module initialization times before they are merged,
ensuring downstream consumers aren't impacted by unexpectedly slow
startup times.

## Changes Included
* **GitHub Actions Workflow**: Created a new workflow
(`.github/workflows/import-profiler.yml`) that triggers on PRs and merge
groups. The workflow is pinned specifically to Python 3.15.
* **Native CI Integration (No template bloat)**: Rather than polluting
the central gapic-generator template (`noxfile.py.j2`) and forcing
updates across 150+ packages, the CI script (`ci/run_single_test.sh`)
natively handles the profiler. It automatically spins up a lightweight
virtual environment, installs the target package, and runs the profiler.
* **Dynamic Differential Checks**: Enhanced `ci/run_single_test.sh` to
checkout `HEAD^1` (the main branch), generate a baseline CSV profile,
and then diff it against the PR branch. If the Median (P50) import time
of the PR degrades by >100ms compared to the baseline, the CI check will
fail. *(Note: Using Median instead of P99 ensures stability against
intermittent CPU spikes on GitHub Action runners).*
* **Safety Backstop**: The script still enforces an absolute
hard-failure backstop of 5000ms for extreme regressions.
* **Conditional Execution & Graceful Skips**: The pipeline verifies if a
valid `setup.py` exists before attempting to profile, gracefully
skipping directories that are not valid Python packages.

## Developer Interactions
If a developer fails this CI check due to an import latency regression,
they can reproduce and debug it locally by running the profiler script
with the `--cprofile` flag (`python scripts/import_profiler/profiler.py
--package <their-package> --cprofile`). This will generate a cProfile
stack trace breakdown of the import time, allowing them to pinpoint
exactly which new dependency or module initialization is causing the
latency spike.

Related PRs
*   Builds upon the import profiler tool added in #17467
*   Regression test proving the CI catches regressions: #17690

---------

Co-authored-by: Chalmer Lowe <chalmerlowe@google.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
@parthea

parthea commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Closing as #17657 was merged

@parthea parthea closed this Jul 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants