[libcxx-commits] [libcxx] [llvm] [libc++] Trigger the benchmark-request job more often (PR #216003)

[Louis Dionne via libcxx-commits]

https://github.com/ldionne created https://github.com/llvm/llvm-project/pull/216003

With the test suite taking under 1h to complete, it makes sense to trigger at least every 30 minutes so we don't leave available capacity unused.

>From 3717e5d010daafcd6e67963c2daeb327b08d143b Mon Sep 17 00:00:00 2001
From: Louis Dionne <ldionne.2 at gmail.com>
Date: Thu, 13 Aug 2026 05:41:19 -0400
Subject: [PATCH] [libc++] Trigger the benchmark-request job more often

With the test suite taking under 1h to complete, it makes sense to
trigger at least every 30 minutes so we don't leave available capacity
unused.
---
 .github/workflows/libcxx-benchmark-cron.yml | 4 ++--
 libcxx/utils/ci/lnt/README.md               | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/.github/workflows/libcxx-benchmark-cron.yml b/.github/workflows/libcxx-benchmark-cron.yml
index 1bc224eb7fc74..b5854376a37cf 100644
--- a/.github/workflows/libcxx-benchmark-cron.yml
+++ b/.github/workflows/libcxx-benchmark-cron.yml
@@ -16,8 +16,8 @@ permissions:
 
 on:
   schedule:
-    # Trigger every hour, off the hour boundary to avoid popular times.
-    - cron: '37 * * * *'
+    # Trigger every 30 minutes, off the hour boundary to avoid popular times.
+    - cron: '7,37 * * * *'
   workflow_dispatch:
     inputs:
       dry-run:
diff --git a/libcxx/utils/ci/lnt/README.md b/libcxx/utils/ci/lnt/README.md
index 5f8af9b55ba87..568b401f8da48 100644
--- a/libcxx/utils/ci/lnt/README.md
+++ b/libcxx/utils/ci/lnt/README.md
@@ -5,9 +5,9 @@ This directory contains utilities for continuous benchmarking of libc++ with LNT
 ## Gathering historical performance data
 
 When generating historical performance data, benchmarking every commit of libc++
-is prohibitively expensive since a single run of the benchmark suite takes a few
-hours. Furthermore, generating this data from scratch is expected to be common,
-since it must happen whenever a fixed parameter like the compiler or the OS changes.
+is prohibitively expensive. Furthermore, generating this data from scratch is
+expected  to be common, since it must happen whenever a fixed parameter like the
+compiler or the OS changes.
 
 Instead, the tools in this directory aim to make it possible to generate historical
 performance data quickly with coarse granularity, with the goal of then generating