⚡ Optimize Date instantiation in buildHeatmapFromRepoPushes

[is0692vs]

💡 What: Optimized the loop in buildHeatmapFromRepoPushes to avoid creating a new Date object and calling toISOString 42 times. The new logic uses a single Date object that is mutated using setUTCDate and manually formatted to YYYY-MM-DD.
🎯 Why: The previous implementation created 42 new Date objects and generated strings via toISOString().slice(0, 10) which is slow and causes unnecessary object allocations.
📊 Measured Improvement: Benchmarks show performance improved from ~6.77s to ~2.06s for 100k runs (a ~70% speedup) over the baseline.

---

PR created automatically by Jules for task 2279441619870337782 started by @is0692vs

Greptile Summary

buildHeatmapFromRepoPushes の42日分の日付生成を、反復ごとの Date 生成と toISOString 呼び出しから、単一の Date の更新とUTC日付の手動整形へ変更しています。

• 反復処理における Date オブジェクトの割り当てを削減
• UTC基準の42日間と YYYY-MM-DD の出力形式を維持

Confidence Score: 5/5

このPRは安全にマージできると考えられます。

UTC日付の加算とゼロ埋めされた日付キーは従来のISO形式と一致し、ヒートマップの42日間の範囲および集計キーの契約を維持しています。

Important Files Changed

Filename	Overview
src/lib/cardDataFetcher.ts	ヒートマップの日付キー生成を効率化しており、月・年・うるう年の境界を含めて従来処理と同等のUTC日付列を生成します。

_{Reviews (1): Last reviewed commit: "perf: optimize Date instantiation in bui..." | Re-trigger Greptile}

Context used:

• Knowledge Base — Card Data Pipeline

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
github-user-summary	Ignored		Aug 7, 2026 6:48am

[coderabbitai]

Warning

Review limit reached

@is0692vs, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 53 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: f38afe07-a87c-4614-bcd8-ee1006c667c0

📥 Commits

Reviewing files that changed from the base of the PR and between eb95c48 and 24a2665.

📒 Files selected for processing (1)

• src/lib/cardDataFetcher.ts

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Optimize heatmap date key generation in buildHeatmapFromRepoPushes

✨ Enhancement 🕐 Less than 10 minutes

AI Description

• Rework heatmap initialization loop to reuse a single UTC Date instance.
• Replace toISOString slicing with manual YYYY-MM-DD formatting for day keys.
• Reduce allocations in 42-day window setup to improve runtime performance.

Diagram

graph TD
  A["buildHeatmapFromRepoPushes"] --> B["start (UTC)"] --> C["current Date (mutated)"] --> D["format YYYY-MM-DD"] --> E[("dayCounts Map")]
  A --> F["repos pushes"] --> E

  subgraph Legend
    direction LR
    _fn["Function"] ~~~ _data["Data object"] ~~~ _db[("Map/Store")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use a fast date formatter utility (e.g., date-fns formatISO)

• ➕ Less chance of subtle formatting bugs
• ➕ Improves readability/intent vs manual string building
• ➖ Adds/expands dependency surface (or uses heavier formatting code paths)
• ➖ May be slower than manual formatting depending on implementation

2. Compute day keys via epoch-day integers, format only at output

• ➕ Avoids Date mutation and repeated UTC extraction entirely
• ➕ Can make counting logic simpler and faster for large datasets
• ➖ More invasive refactor; harder to reason about without careful UTC handling
• ➖ Still needs a final formatting step to YYYY-MM-DD

Recommendation: The current approach (single UTC Date mutated with setUTCDate plus manual YYYY-MM-DD formatting) is a good, low-risk performance win that avoids repeated allocations and toISOString overhead. If this logic is reused elsewhere or becomes more complex, consider centralizing the YYYY-MM-DD formatter (with tests) to reduce the risk of future UTC/padding regressions.

Files changed (1) +6 / -4

Enhancement (1) +6 / -4

cardDataFetcher.tsReuse a single UTC Date and manually format heatmap day keys +6/-4

Reuse a single UTC Date and manually format heatmap day keys

• Replaces per-iteration Date allocation and toISOString().slice(0, 10) with a single Date instance incremented in-place. Generates YYYY-MM-DD keys by reading UTC year/month/day with explicit zero-padding, reducing allocations in the 42-day initialization loop.

src/lib/cardDataFetcher.ts

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[is0692vs]

Closing as a duplicate of the older #545; both optimize Date creation in buildHeatmapFromRepoPushes.