Python version of phase_stats.py calculation - #1787
Conversation
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
Warning Review limit reached
Next review available in: 39 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughPhase-stat aggregation now fetches all run measurements once, groups them into per-metric time series, and computes phase aggregates in memory. New helpers reproduce percentile, derivative, sampling-rate, and phase-boundary calculations, including the first post-phase sample where applicable. The phase loop uses these calculations for each metric and resolves carbon-intensity providers while recording warnings for multiple providers. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
tools/phase_stats.py (1)
28-28: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueOptional: trailing space in status message / prefer logging.
print('Fetched data for ', args.run_id)emits"Fetched data for <id>"(double space from the comma separator). Minor cosmetic nit; consider an f-string or the project's logger for consistency.♻️ Optional tweak
- print('Fetched data for ', args.run_id) + print(f'Fetched data for {args.run_id}')
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: faa34ad5-df0f-4d1c-848d-42f244669fae
📒 Files selected for processing (2)
lib/phase_stats.pytools/phase_stats.py
|
@coderabbitai review |
✅ Action performedReview finished.
|
[skip ci]
|
@ribalba PR now ready for review. Since it is in the crucial calculation part please give it an extra pair of eyes |
|
@coderabbitai review |
✅ Action performedReview finished.
|
✅ Action performedReview finished.
|
|
Eco CI Output [RUN-ID: 30005732884]:
🌳 CO2 Data: Total cost of whole PR so far: |
|||||||||||||||||||||||||||||||||||
[skip ci] * main: (fix): Custom metrics now allows valid floats and even negative numbers also (ci): Added Eco-CI measurement after setup (test-fix): Downgrading python version as 3.15 did not exist yet Upgraded Python version in CI/CD (feat): Making GitHub Action two step to debug setup vs. run better Bump actions/setup-python from 6 to 7 in /.github/actions/gmt-pytest (#1786) Bump fastapi from 0.139.0 to 0.139.2 (#1780) (feat): All config files are now in a config folder instead of clobbering the root dir and docker dir (#1793) Updated Cloud Energy Bump pandas from 3.0.3 to 3.0.5 (#1790) Bump aiohttp from 3.14.2 to 3.14.3 (#1792) Bump cachetools from 7.1.4 to 7.1.5 (#1791) (fix): 0 Values in CPU Utilization Provider for linux do not lead to Floating Point Exception anymore
| if carbon_intensity is not None: | ||
| phase_warnings.add(f"More than one carbon intensity provider is configured. Now using {metric}") | ||
| carbon_intensity = value_avg | ||
| chosen_carbon_metric_name = metric |
There was a problem hiding this comment.
Must't this be set before all the calculations are done?
| derivative_max = weighted_derivative_max # pylint: disable=possibly-used-before-assignment | ||
| derivative_min = weighted_derivative_min # pylint: disable=possibly-used-before-assignment | ||
|
|
||
| return ( |
There was a problem hiding this comment.
I would probably make this an object as I found this quite confusing to map to vars
| WHERE mm.run_id = %s | ||
| ORDER BY mv.measurement_metric_id ASC, mv.time ASC | ||
| """ | ||
| metric_time_series = {} |
There was a problem hiding this comment.
Will this not become huge on a very long run? What happens when you run this on a 45 min run?
This PR speeds up the processing for the phase stats by moving calculation out of the DB hotpath.
Analysis
We first assumed the bottle neck was the SQL queries, which became quite complex, or the big database with the big index (In our live DB of ~ 100 GB of raw measurement values)
However the slow down was the network connects. We make a separate SQL query per metric and phase. This can sum up to 6 x 30 calls easily. With setup and teardown each network call takes about 1 second.
Now we only do one big query to fetch all the values resulting in a 100x speedup
Summary
MAX_POSTGRES_BIGINTand centralizedDecimal()handling.