【低レイヤ最適化】1BRC for traP を開催しました！

突然ですが、

みなさん 1BRC というコンテストをご存じですか？　1 Billion Rows Challenge の略で、10億行(!!)のデータを処理する速度を競うコンテストです。10億行ともなるとそのデータ量は何GBにも及び、様々な最適化テクニックを駆使してデータを処理します。

もっと詳しく知りたい人は、maguro さんのこの記事を読むと良いと思います。様々な最適化テクニックを駆使して 1BRC を攻略する様子が垣間見えます。

traPでもやりたい！

こんなに面白いコンテストがあることを知って、せっかくなら部内でも開催したいなぁと思うわけです。ということで善は急げ、すぐに企画を始めました。

もともとのコンテストは観測所ごとの気温データに対して最小値、最大値、平均値を求めるコンテストなのですが、せっかくならこれを traP 向けに改造したいよね、と。

と思って2ヶ月が経過、、、

まずい！放置しすぎ！　ちゃんとやりたい気持ちがあったので、急いで準備しました。データも作って、テストプレイもして、ベンチマーカー上で計測できるような環境を整えて、かっこいいダッシュボードも作って、、、、みたいな感じで準備することが思ったより多くて大変でした。でも Codex が全部やってくれたので OK です。

勇気を出しました pic.twitter.com/j3el9Kil1i
— しーぴー 🍀 (@__cp20__) July 10, 2026

いざ、開催！

2026年7月18日 (土) 10:00 から7月19日 (日) 20:00 までの34時間で開催しました。最初こそ計測環境が上手く動かない、あるいはサーバーが不安定になるといったトラブルがあったものの、2日目はある程度安定して競技を続けることができました。

コンテストサイトは一般に公開されているので、興味がある方は覗いてみてください。

ルール紹介

ちゃんとしたルールはコンテストサイトに書いてあるのでそちらを参照して欲しいのですが、概要だけかいつまんで紹介します。

参加者は traQ のメッセージ一覧を模した CSV を読み込み、それをチャンネルと月ごとに集計することを求められます。例えばこのような入力が与えられたら、

unix_timestamp,channel_path,message_length,stamp_count
1798761600,team/dev/api,120,3
1798761660,team/dev/api,80,1
1801440000,team/dev/api,200,0
1798761720,team/web,50,2
1798761780,team/web,70,4

次のような出力を返します。

team/dev/api,2027-01=80/100.00/120/2/4
team/dev/api,2027-02=200/200.00/200/1/0
team/web,2027-01=50/60.00/70/2/6

数値が5つ並んでいますが、左から、メッセージ長の最小値、平均値、最大値、メッセージ数、スタンプの合計数です。

この例だとものすごく短いですが、実際は10億行約25GBのデータを処理して12万行の出力を出します。なのでナイーブに書くと処理に10分以上かかってしまうんですが、これをいかに速く処理するかの勝負になります。

結果発表～～～～

最終的には1位が @zoi_dayo 、2位が @Citrine 、3位が @Ponjuice でした。 (もっと詳しい順位はサイトから見れます)　また参加者は31人、そのうち実行時間が計測できたのは29人で、全1116件の提出がありました。雑に企画した割には結構たくさんの参加者を集められて良かったです。

ただしレギュレーション違反の失格者が10人以上出たのは残念でした。詳しくは講評のところで述べます。

講評

多くの参加者が1桁秒に辿り着いていて、さらに3秒台、2秒台と詰めている参加者も少なくない数いたのはかなり良かったと思います。それはおそらく AI Agent の台頭の影響が大きかったのかな、と。実際上位陣はほぼ全員 AI Agent を使っているはずです。

また、本家 1BRC に比べてやや複雑なデータを用意したのですが、多くの参加者が最適化の過程で安全ではない最適化をしてしまっていました。今回のお題で最適化を進めていると、チャンネルごとの HashMap を引くのが遅いという事実に気が付くはずです。それが遅いのはキーであるチャンネル名が string であり、その比較が遅いのが原因で、これは例えば64bit整数などのハッシュを取ってそれをキーにすることで解決できます。しかしこれではキー名の衝突が起きたときに誤った処理が行われてしまうので、ハッシュ衝突の処理が必要になります。この処理を行わずに単にハッシュを取った参加者がかなり多かったです。

ただ実際単純にチャンネルをキーにした HashMap は遅いので、例えばハッシュを取った上でさらにチャンネル名を比較して正しいか確認する、といった処理が考えられます。ハッシュのエントロピーが十分にあれば衝突はほぼ起きないので基本は比較処理だけのコストで済みます。もっと言えばチャンネル名は10000種類以下であることが仮定として使えるので、10000種類のチャンネルが出現した後は厳密なチャンネル名の比較をスキップ出来ます。このように厳密性を崩さずに最適化を進めることが重要になります。

とはいえ2秒台を達成している参加者はそういう最適化をしてきたと思うので、流石と言わざるを得ませんね。

さて、

具体的にみんながどういう最適化をしたのかが気になりますが、それは皆さんのブログ公開を待つことにしましょう。それでは。

おまけ

コンテストの裏でボクも Codex (GPT-5.6 Sol Ultra) を走らせて最適化をさせてました。トークンは異常な速度で溶けて行きましたが、その分成果は出ました。

public で 1.5 秒台、private でも 1.7 秒台です。圧倒的な1位です。お前が優勝だ、Codex。

Codex の成果はここから見れます。参考までに。