You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Reduce flakiness of import-profiler presubmit #18987
In PR #18986, the import-profiler presubmit failed with:
FAILURE: Import time regression of 244.54 ms exceeds both the absolute threshold (100.0 ms) and the relative threshold (201.76 ms, 15% of baseline Median).
I inspected the PR, but couldn't spot any obvious regression. The surface of the API has increased, so the increase in baseline is expected. This presubmit should not fail for routine changes. I'm going to propose to increase the baseline diff threshold from 100ms to 300ms, but we should investigate if there are other improvements that we can make in the generated library, and restore the original 100 ms.
Hi @parthea, I investigated the unversioned package entry point. It still imports client and type exports eagerly, while the versioned entry point uses the native lazy imports from #17591.
I have a small generator change to extend that behavior to unversioned aliases, with regression tests and updated goldens. Replaying the original BackupDR API update on Linux ARM64 reduced the bare-import increase from 266.30 ms to 1.80 ms. This defers loading and dependency errors until first use, and leaves the 300 ms workaround unchanged.
Would a PR for this specific change be useful here?
Activity
ci: temporarily increase import diff threshold from 100ms to 300 (#18988
GouthamMahesh commentedon Nov 10, 2026
Hi @parthea, I investigated the unversioned package entry point. It still imports client and type exports eagerly, while the versioned entry point uses the native lazy imports from #17591.
I have a small generator change to extend that behavior to unversioned aliases, with regression tests and updated goldens. Replaying the original BackupDR API update on Linux ARM64 reduced the bare-import increase from 266.30 ms to 1.80 ms. This defers loading and dependency errors until first use, and leaves the 300 ms workaround unchanged.
Would a PR for this specific change be useful here?
GouthamMahesh commentedon Nov 10, 2026
Opened #19032 with the generator change and tests.