⚡ Bolt: Optimize batch key generation in push_rules

[google-labs-jules]

💡 What:

• Added _BATCH_KEYS constant to pre-calculate hostnames[{i}] strings.
• Updated push_rules to use these cached keys when constructing the payload.
• Added a fallback to dynamic generation for safety.

🎯 Why:

• The previous implementation formatted a new string f"hostnames[{j}]" for every single rule being pushed.
• For large profiles with 100k+ rules, this resulted in hundreds of thousands of unnecessary string formatting operations.
• While the network IO is the main bottleneck, this optimization reduces pure CPU overhead in the tight loop.

📊 Impact:

• Micro-benchmark showed ~3x speedup for the dictionary construction loop (0.5s vs 1.6s for 5M ops).
• Real-world impact is minor but measurable in CPU time for large rule sets.

🔬 Measurement:

• Verified with bench_strings.py (micro-benchmark).
• Validated functionality with main.py --dry-run.

---

PR created automatically by Jules for task 13653136723170395035 started by @abhimehro

[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.

[Copilot]

Pull request overview

This PR optimizes batch key generation in the push_rules function by pre-calculating the dictionary keys used when constructing API payloads. The optimization addresses CPU overhead when processing large rule sets (100k+ rules).

Key Changes:

• Pre-calculated _BATCH_KEYS constant containing 500 formatted strings (hostnames[0] through hostnames[499])
• Updated push_rules to use cached keys instead of formatting strings in the hot loop
• Added conditional logic with fallback to dynamic generation for edge cases

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The fallback condition else at line 509 is unreachable because batches are created with a maximum size of BATCH_SIZE (500), and _BATCH_KEYS is pre-calculated with exactly BATCH_SIZE elements. Since j enumerates over a batch that never exceeds BATCH_SIZE elements, j will always be in the range [0, BATCH_SIZE-1], making the condition j < len(_BATCH_KEYS) always true. The else branch can never execute.

Suggested change

	if j < len(_BATCH_KEYS):
	data[_BATCH_KEYS[j]] = hostname
	else:
	data[f"hostnames[{j}]"] = hostname
	data[_BATCH_KEYS[j]] = hostname

[Copilot]

The comment claims "~1.1s of CPU time per 10k batches" but this appears inconsistent with the PR description which states "Micro-benchmark showed ~3x speedup for the dictionary construction loop (0.5s vs 1.6s for 5M ops)". For 10k batches with BATCH_SIZE=500, that would be 5M operations total (10,000 * 500 = 5,000,000), which aligns with the benchmark. However, the savings would be approximately 1.1s (1.6s - 0.5s) for all 10k batches combined, not "per 10k batches" which suggests repeated measurements. The wording should be clarified to say "per 10k batches" or "for 10k batches" to avoid ambiguity.

Suggested change

	# This saves ~1.1s of CPU time per 10k batches by avoiding f-string interpolation.
	# This saves ~1.1s of CPU time for 10k batches by avoiding f-string interpolation.

[abhimehro]

Superseded: Performance optimizations already in main.

[google-labs-jules]

Superseded: Performance optimizations already in main.

Understood. Acknowledging that this work is now obsolete and stopping work on this task.